Re: VTree RFC

[Havoc Pennington <rhp zirx pair com>]

On Wed, 10 Mar 1999, Peter Teichman wrote:
> 
> We discussed a thin tree widget a while ago, and I was planning on putting
> some code down for an implementation later this week.. I finally have a
> week and a half or so of hacking time. I'd be glad to help out if you
> need it.
>

Cool! 
 
> > The pixtext type is just a convenience thing, since you could also
> > user-draw it.
> 
> What would this be used for? Why not provide a function to draw it (and
> possibly some other common data types) with the widget itself? Then you
> would just set the drawing function to whatever you want, whether it be you
> own rendering function or one of those. I don't see the need for a
> distinction.. GtkVTreeCellType appears to just complicate things, at first
> glance.
>

You're probably right for the pixtext. It is just sugar. You need to
special case the radio/toggle buttons though.

Hmm... if I do the thing where some cells pass events to the vtable, I
could potentially nuke the CellType enum and make it very clean. Not a bad
idea.

One virtue of this sort of tree is that it avoids featuritis fairly well,
since it's user-extensible.
 
> I've been thinking - perhaps a VList widget is in order, as well. I like
> the lightness of this widget, and there are certainly places where a more
> lightweight list could be useful.
> 

VTree can be a list, just don't have a tree column and don't have any of
the nodes be expandable. The two optional functions that use indices are
meant for lists, or for trees where the user already keeps a count of rows
in the tree. You can use them to have a list that's implemented as an
array, should be quite small and fast. However, I'm not sure it will work
because traversing the nodes may be necessary anyway to figure out where
the selection has gone when the structure changes and that sort of thing.

If you don't implement the functions that provide row count and
constant-time row indexing, then VTree will have to count the rows in the
tree/list every time there's a tree structure change. This is the only
slow operation the widget has to do, I would like to get rid of it but
don't think it's possible. It isn't noticeably slow in gnome-apt but that
is only a few thousand rows and the iteration is over vectors with a bunch
of inlined code.

I just realized the vtable assumes single-row selection, I should fix
that. Also I need to inform the draw functions whether the row is
selected...

Havoc