'Huge list' widget

[Lionel Ulmer <lionel ulmer free fr>]

Hi all,

First, my requirements :

 - displays just 'plain text' lines (no need for columns) where only the
   color may change (ie no embedded icons, font change, ...)

 - pretty huge lists (can go up into the 100.000 items)
 
 - filling need to be fast as the list is built in a working thread and it's
   a time-out handler which fills (by polling the working thread) the list
   for the GUI (so I do not want the UI to freeze each time the time-out
   handler adds element to the list).

I looked a bit at how GtkTreeView handles these requirements and it's pretty
slow (at least on my box and will even be slower 'in production' on
relatively ancient Sun workstations). Moreover, either we let GTK handle all
the list, or all the data will be twice in memory. In my case, it's not
possible to let GTK handle it so it's also very memory intensive.

So my idea was to write what I call a 'user-space list widget'. That means
that the widget would only know about the list items displayed on screen (on
scroll, it would each time ask for the new list items to display). 

This meets my requirements as :

 - the list can be huge as GTK+ won't care at all, it only knows about at
   most 50 elements
   
 - adding elements to the list will only change the scrollbar, nothing else
   => it will be pretty fast


Now the question is that I thought doing that as follows :

 Widget is realized / resized / scrolled / ... and detects that some new
 lines it does not know about are displayed. It generates a signal.
 
 This signal needs to he handled at the application side which would then
 call a widget API to tell the content of each missing line.
 
 At the return of the signal generation, the widget would display the lines
 on screen.

Anyone has any thoughts / comments on this ?

Anyway, I will first try to implement this without creating a new widget
(just by doing it in a Pixmap and displaying this Pixmap on a plain standard
Gtk widget) and see the results :-)

                      Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/