Re: [Tile-dev] Strawman Tree widget API

[Joe E. <jen...@fl...>]

Brian Griffin wrote:

> Headings need to be buttons with -commands, and support label/image
> combinations

Like the up arrow/down arrow sort direction indicator
seen on the right side of the header in some interfaces?
Pretty easy to add.

Sort direction indicators probably ought to be themable;
the best way to handle this might be to specify a collection
of "stock images" that applications could reference and
themes could override.


> > Some things I'm not too keen on:
> >     $tree insert $index $parent $itemid ? ... options ... ?
>
> I different approach may be to have two methods, one that adds an item
> after the index as a sibling, and another that adds an item as a child
> of the index.  Which raises a question: are indexes relative to the
> parent node, or absolute?  If a parent node is collapsed, what happens
> to the subsequent indexes?

The indexes are relative to the parent; they're
part of the data model, not the display model, so
expanding/collapsing earlier nodes won't affect the
position.

> > [...]
> > I'm not sure how useful user-supplied node
> > IDs are; it may be better to just use widget-generated integers
> > like the canvas does.  [...]
>
> Without a UID, how do you find something in the tree?

There's still UIDs, they'd just be generated automatically
by [$tree insert ...].  Either sequential integers or
opaque tokens like "item119".

> > I don't like the overloaded nature of the "-columns" argument --
> > either an integer representing the number of columns or a list
> > of symbolic column names. [...]
>
> Following the "everything-is-a-string" paradigm, I would just say that
> all columns are named; period.  This also gives you a default header label.

I'm *really* tempted to do this.

The main reasons for allowing the user to just specify the
number of columns is that it seemed slightly more intuitive
(to get 5 columns, say "-columns 5"); and the data might not
have homogeneous columns, in which case there wouldn't be a
meaningful identifier for each column.

But I think I'll do it anyway.  If anyone complains loudly
enough, we can put it back in.


> > [...]
> > The -height option should really specify the desired number of
> > visible items, not the height in pixels.  I'm not sure what
> > units '-width' ought to take.
> >
> I've never liked "item" based sizing.  It leads to funky window resizing
> behavior.

I hadn't planned on implementing gridded geometry; the window
would still resize smoothly.  Just that when you create a tree widget
you can specify the desired number of visible rows instead
of the height in pixels.  This seems more useful to me.
(As precedents, the listbox and text widgets work this way.)


> I would also like to see an incremental or dynamic interface that allows
> for support of larger datasets.  We have an interface on our tree that
> is comprised of three configure options:  [... description elided ...]

I can see where this would be useful, but I don't
want to use a callback-style interface by default
for supplying data.  Instead, the widget should generate
a rich enough set of virtual events that you can implement
this sort of thing on top of it.

I've filed away your description, it'll be a good use case
for further API design.


--Joe English

  jen...@fl...