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 _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
