|
From: Joe E. <jen...@fl...> - 2004-09-23 16:10:48
|
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 :-)
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.
+ 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.
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.
I'm not too sure about the names 'open' and 'close'.
I'm also not too sure about the number of widget commands;
maybe some of these should be merged into a subensemble.
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?
--Joe English
jen...@fl...
|