Re: VTree RFC

[Peter Teichman <pat4 acpub duke edu>]

On Wed, Mar 10, 1999 at 03:09:01AM -0500, Havoc Pennington wrote:
> 
> On Wed, 10 Mar 1999, Peter Teichman wrote:
> 
> You're probably right for the pixtext. It is just sugar. You need to
> special case the radio/toggle buttons though.

Why is this? In the radio/toggle case, you would set up a data structure
that contains the button state & provide a draw function that draws it in a
checked or unchecked manner depending on that state.

You would attach a handler to whatever click event the VTree provides to
change that state.

> 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);

make_text_item is a function that knows how to render the data ("text
message") as a GnomeCanvasItem. It returns a CanvasItem that displays that
data.

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.

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

Ok, I like this way of doing it. I haven't put much thought into whether we
would need to traverse the structure anyway, though.

VList is certainly not needed, you're right.. Just don't insert any
children into your tree structure. Cool.

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

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

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

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.

There are cases where you might want to invert the selected region, for
readability, but then you also need to know the background it is being
rendered on. Not fun.

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.

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