|
From: Brett S. <bre...@ya...> - 2004-09-23 18:08:59
|
I have only briefly looked at the manpage, but I had a couple of comments off the bat (see below): --- Joe English <jen...@fl...> wrote: > > 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: > One thing I use explicit node names for is so that I can identify the node during callbacks (i.e. when selected). Think of it as "client data" in the node name. I'm not sure if this is the right way to do this or not, but I find it comes in handy. Of course, one could just keep a reference to the node id (generated from treeview) and client data in a separate structure, but I kind of like keeping it together. Not sure if I am explainging this well enough... One other thing that I think is missing, is a way to find out if a node exists. In BWidgets, it would be: $widget exists <nodename> I actually do use this in existing code. I didn't see anything comparable in the treeview manpage (unless I missed it). Of course, a catch could be used, but I like the explicit "exists" command. that's it for now...thanks for the work. --brett |