Re: VTree RFC

[Havoc Pennington <rhp zirx pair com>]

On Wed, 10 Mar 1999, Peter Teichman wrote:
> 
> You would attach a handler to whatever click event the VTree provides to
> change that state.
>

The issue is whether to permit that, but as you say I got around to
saying that here:
 
> > 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.
> 
> Maybe we are talking about the same thing, at this point. The tree should
> only know how to tell the item to draw itself. No item state is known by
> the tree itself (including what type of thing the item is).
> 
> With ThinkOutline, all I do to add a text item (for example) to the tree is:
> 
> child = think_outline_content_new_with_data ("text message",
>                                              (void *)make_text_item);
> g_node_append (parent, child);
> 

If I understand what this does, it doesn't address one issue the VTree is
meant to: the case where the *entire tree* - content and structure - can
change at any time. That's what happens in gnome-apt, any time you click a
radio button. So with CTree you have to clear all nodes and then stuff
7,000 ten-column nodes - far too slow to be usable if it happens on every
radio button click!

That's why I'm using a vtable and not even the "item" approach.

> If we apply this same idea to VTree, make_text_item would become
> draw_text_item. It would probably be passed the possible bounds of that
> item & the item data itself.
> 
> Does this sound reasonable? vtree_node_draw would probably make the call to
> the item's drawing function.
>

Yes that is basically right except that the concept of an "item" is
application defined, VTree passes it around blindly as a gpointer. The
interface implemented by the VTree vtable is for an entire tree rather
than any individual item.
 
> Hmm, what are the counts used for? I don't keep track of the number of
> nodes in a ThinkOutline at all.
>

Scroll bars.
 
> The VTree itself should draw a box around the selected row, or whatever the
> main selection indicator is. Passing a 'selected' flag into the draw
> function is only needed if you want the data to be rendered differently
> depending on the selection. I don't allow this with my Outline widget,
> because I couldn't think of a case where I would really need it.
>

It's not hard information to provide though, so why not. Someone might
want to use a different pixmap with the selected item or something.
 
> Here's another thing to think about: what about drag & drop? CList & CTree
> allow DnD reordering of the structure below. It would be great to allow
> this with the VTree, but it does require knowing more about the structure
> the tree is stored in. At that point, you either add movement functions to
> the table or you force the user to use a specific data structure.
> 
> I went the latter route with the Outline widget. It forces you to keep your
> data in a tree of GNodes.
> 

I'm going with the former for the reason described above - part of the
purpose of the widget is to avoid rebuilding a copy of the data to reflect
changes. Also, to demand-create the tree; say you have a tree representing
a filesystem. You don't want to stat the whole filesystem and stuff it in
the tree. You want to stat directories when they are expanded and not
before. VTree won't ask for any row it doesn't intend to display, so that
problem is solved automatically. 

As a side benefit, interfacing with libraries that don't use GNode, such
as the Apt library, is a good bit easier this way.

Havoc