Re: VTree RFC

[Peter Teichman <pat4 acpub duke edu>]

On Wed, Mar 10, 1999 at 06:42:19PM -0500, Havoc Pennington wrote:
> 
> On Wed, 10 Mar 1999, Peter Teichman wrote:
> > 
> > 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!

Hmm, that is true. At that point, I would dirty nodes with changed state
and redraw the tree. I don't know if that is feasable (or desired) with the
VTree architecture, though.

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

Right. I didn't mean for it to sound otherwise - having a gpointer to some
data of unknown structure, and a pointer to a function to render it, is the
way to go.

> > Hmm, what are the counts used for? I don't keep track of the number of
> > nodes in a ThinkOutline at all.
> >
> 
> Scroll bars.

Ah, ok. The canvas does that work for me, with ThinkOutline.

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

Ok, sounds safe.

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

Sounds good to me. Should we add those movement functions, to facilitate
DnD?

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

Ah, I hadn't thought of that. Very nice.

Pete
-- 
Peter Teichman
pat4@acpub.duke.edu