RE: [Tile-dev] Strawman Tree widget API

[Andreas K. <and...@ac...>]

> As a starting point for discussion, I've posted
> a strawmanpage here:
>
>     <URL: http://tktable.sourceforge.net/tile/doc/treeview.html >
>
> The documented interface is still incomplete, but I think
> it's a pretty good start.  I *hope* that it's simple enough
> to figure out how to use the widget from the manpage alone --
> I've omitted the EXAMPLES section on purpose to test if that's
> actually the case :-)

So far I had no trouble.

I would change 'remove' to 'detach', the inverse opration is 'attach'.
If 'remove' is kept as name the inverse should be 'add'.

Horizontal scrolling is definitely something which should be done. ... Might
be restricted to the values though, and not the hierarchy column at the
left.

> Stuff that's missing:
>
> + Need to keep track of an "active" or "focussed" item;
> + Support for selections;
> + Drag and drop support, or (more likely) a foundation upon which
>   drag and drop support could be built.

Foundation. Useful for other widgets as well - drag/drop entry values ...

> + A way to specify column headings, column widgths, and other stuff

> + Might want to be able to turn different components on and off:
>   column headings, open/close indicators, tree "connecting lines",
>   maybe even the tree labels to support "pure" multicolumn listboxes.

Yes.

> Some things I like about this design:
>
> Separate -columns and -displaycolumns options make it easy
> to hide or reorder columns without having to change all the
> item -values.
>
> It works as a plain tree (leave -columns empty and don't
> supply -values for any items), and -- almost -- as a plain
> multicolumn listbox (create all items as children of the root
> and leave out -text and -image.)
>
> Some things I'm not too keen on:
>
>     $tree insert $index $parent $itemid ? ... options ... ?
>
> I copied this straight from the BWidget Tree, just to have a
> starting point.  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.  This would reduce the number of required
> arguments from 3 to 2; and since then it's incompatible with
> BWidget anyway we can swap the order of the first two arguments
> and make it:
>
> 	$tree insert $parent $index ?... options ... ?
>
> which seems more natural to me.

> 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.  But I *really* like the ability to
> have named columns, and if we had separate -numbercolumns
> and -columnnames options it'd be more work for users and for
> the widget to ensure they were always consistent.
>
> Specifying "-displaycolumns {}" (the default) means that all
> columns are shown, in order.  There is no way to say "do not
> display any columns".
>
> 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.
>
> The return value of [$tree identify $x $y] is a hairball.

A bit yes.

> I'm not too sure about the names 'open' and 'close'.

	Alt. names: 'show' and 'hide'.

> I'm also not too sure about the number of widget commands;
> maybe some of these should be merged into a subensemble.

All the item specific commands maybe ?


> Other stuff to think about:
>
> Item states: there are a few item states that the tree indicator
> element should be aware of, so it can select an appropriate display
> based on whether the node is open or closed, and whether or not
> it's a leaf element.  None of the currently-defined TTK_STATE_*
> flags really match those concepts well.  "selected" might serve
> for open/closed, except that we also want to support listbox-style
> selections.  I'm using the USER1 and USER2 state flags internally
> right now for open and nonleaf, respectively; but there really
> ought to be a mechanism for assigning meaningful names.
>
>
> Comments?

Should I open the discussion about separation of widget and data ?

	I.e. that the tree data is a separate object the tree widget/view
	connects to ? Multiple widgets for one tree, different visual
	state, for the same data ? Ability to use special tree data
	objects which have no actual tree in memory ? (= virtual trees)

If not, just snip this part from any reply.



Thanks for starting the work.

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com, a division of Sophos
	Tel: +1 604 484 6491