[PyKDE] large tables problem

[Jim Bublitz]

On Wednesday 23 June 2004 06:11, Vicent Mas wrote:
> El Wednesday 23 June 2004 07:10, Jim Bublitz escribio:

> > If your application allows it, you can operate the table with fixed
> > number of cells/fixed amount of memory, reload the cells as necessary
> > (don't destroy/construct new cells), and overload the navigation
> > methods (cursor up/down, page up/down, home, end, and the equivalent
> > mouse/scrollbar/button operations) to cause a "page fault" and reload
> > the table when navigation is about to go outside the range of rows
> > currently displayed.

> I was thinking about it, and discarded this possibility because I didn't
>  know how to overload the navigation methods. In particular I don't know
>  how  can I do that the scrollbar of a table with let's say 100 rows
>  behaves and looks like the scrollbar of a table with much more rows.
>  Could you give me a clue, please?

I'd really have to look more closely at how QTable is implemented, which I'll 
try to do later today. My guess is that you'll need to install an event 
filter on QTable and catch the key press and mouse events for navigation 
keys. 

For example, for cursor up, you'd check to see if you're at the first row of 
the display. If not, you pass the event to the normal QTable handler; if you 
are at the first row, you adjust the data in the table (hopefully without 
redrawing) so that when you pass the event to QTable, it redraws with the new 
row in the top position.

Event filter documentation begins under QObject in the Qt docs, and there are 
docs for the various event type classes as well.

Some table widgets are implemented so that you can overload either a 
navigation method (usually a large switch stmt with cases depending on key 
pressed), or individual methods for each type of movement.

The scrollbar stuff can be a little trickier. The navigation part probably 
isn't too hard, but getting the slider to size itself to the virtual table 
size instead of the display table size is sometimes difficult because of the 
way the scroll bar code is written. A fixed size small slider is probably 
easier than making it proportional in size to the number of rows (since your 
table will probably always want the minimum size anyway).

> > There are probably some ways to minimize data movement, but the
> > limiting factor for speed is probably redraws. The memory used should
> > then be independent of the table size.
>
> Right. This is exactly the goal I'm trying to achieve. Data movement is
> already very optimized in my application, but the suggestions you pointed
> above still remain to be done.

By "data movement" I meant within the table itself. In the example above 
(cursor up pulls in new row), the simplest way is to shift all the rows down 
one row and then add the new row at the top. That may or may not be an 
expensive operation. Some kind of circular list of rows is probably the most 
efficient way to implement it, but probably isn't compatible with the way the 
table widget is written. Writing a table widget from scratch is a lot of 
work.

You might also check the TrollTech web site or Google and see if anyone has 
contributed or written anything like this. If you can find a customized 
widget, it usually isn't a lot of work to do Python bindings for it (and I 
actually could use something like this myself for some software I never get 
around to writing).

Jim