Re: 'Huge list' widget

[Havoc Pennington <hp redhat com>]

On Mon, Mar 24, 2003 at 11:08:19PM +0100, Lionel Ulmer wrote: 
> 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.

As someone else pointed out, you can write a custom GtkTreeModel,
which may work for you.

> 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 ?

I did this many years ago with gnome-apt. The main problem is just
that writing the UI for a list is very hard. The keyboard navigation,
selection, accessibility, etc. behaviors. But for a custom in-house
app you may be able to ignore all or part of that.

The way gnome-apt worked was even simpler than you describe. It simply
kept track of which list item was at the top of the widget, and
whenever the list changed (or scrolled, or whatever) you just called
gtk_widget_queue_draw() to repaint the whole thing, and it started
drawing with the top list item until it filled the whole widget, then
stopped.

I would not suggest looking at the gnome-apt code as I'm sure it was
totally broken, but the basic approach could still be used.

Havoc