[PyKDE] large tables problem
jbublitz at nwinternet.com
Wed Jun 23 18:34:00 BST 2004
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
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
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).
More information about the PyQt