Re: 'Huge list' widget

[Lionel Ulmer <lionel ulmer free fr>]

> This is not very difficult to do, though a bit laborious (That's why
> they came up with C++ :)

Yeah, for a 'quick hack', this seems like a lot of work :-)

I agree that it may not be as nice and kinda 'throw-away' code but it will
do exactly what I want it to do :-)

> This also solves the problem about having all the data twice in memory:
> your data structure *becomes* the `GtkTreeStore' you use, so you don't
> need to have extra copies.

Well, considering that my application is written 100 % in Python (with the
GUI in PyGTK) I wonder if this would work (ie to give to some C code a model
written in Python).

> One example of this kind of thing is in the source for gconf: there the
> tree in never built: its nodes are created as the user browses the gconf
> tree. (Another example, maybe a bit exotic but fun, would be an locally
> finite infinite tree which can be finitely computed (like the full tree
> of moves in a chess game) Here it is impossible to keep the data in
> memory, because you just can't, but you could come up with a
> implementation of the GtkTreeModel interface which provides the data to
> a view; the gconf case is rather similar to this, actually)

My problem is a bit different : I actually need to have all the data.
Basically, it's a parsing of a huge data log, so I have a lot of
'primitives' and I need to keep track of all of them (I have no idea which
time period the user want to see / which ids are interesting / ...).

So I will have anyway a full list in memory and cannot use 'build the tree
dynamically' tricks.

Moreover, the same list need to be able to be displayed multiple times (but
each time with another set of items displayed). I supposed that this could
be done using some column saying 'Do not display this list item'.

> This is a bit different, because this would, I guess, break the separation
> between the view and the model of your list (which is kind of sad, since
> that scheme is very nicely thought out)

I agree that it's not 'nice'... But I think it's pretty efficient (and it's
my main goal there).

                    Lionel

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