[Tile-dev] a tale of 2 trees

[Jeff H. <je...@ac...>]

Tim Baker wrote:
> Jeff Hobbs wrote:
> > 2.2).  However, if I only needed what a "simpler" treeview would =
provide,=20
> > and
> > it provided it with a memory size of ~20MB for the same app ... does =
that=20
> > not justify a simpler, dedicated widget?
> >
> > Therein lies the real question - if we strongly feel that a simple
dedicated
> > and mega configurable tree widgets (2 separate) are both valuable, =
let's=20
> > get treeview in 8.5, and treectrl in 8.6.
>=20
> Is it only the [style] and [element] commands that blows=20
> treectrl out of the "simple" space into "mega-configurable"?=20
> The high memory requirements are mostly a result of styles=20
> and elements. Whenever people comment that treectrl
> is difficult to use I start brainstorming alternate APIs. It=20
> always comes down to a question of how much control over the
> appearance of items is desired.

Therein does lie the question.  To be honest, I have very little =
exposure to
the treeview widget, whereas I have done quite a bit with treectrl.  I =
have
some comfort that ActiveState's use of treectrl has stressed it to find =
weak
points (and resolve them for the most part).

I don't know much about treeview's track record.  I do know that the =
little
bits I've seen always had /something/ wrong with them.  The
demos/dirbrowser.tcl doesn't scroll right on Windows (adds too much =
space at
the end), doesn't seem to handle the +/- stuff right, the headers have =
several
issues ...  Anecdotally, for those who have had treeview and treectrl
available to them, where treectrl was too complicated to master, they =
more
often turned to BWidget's tree (or tablelist if appropriate) than use =
treeview
due to its lack of features.

I will deconstruct the treeview "oversimplicity" from the dir browser
perspective, since I have done directory views with treectrl.

* The handling of the sort arrow is a built-in feature in treectrl.  In
treeview (like tktable), you would have to manage the same yourself with =
the
-image stuff (which can only be placed left of the label).

* The columns - how do you specify which one has weight?  Resize and =
shrink
behavior?  This is all possible in treectrl, but doesn't appear to be in
treeview.

* Is it possible with treeview to give a full single column a background
without tagging each item (as one would do to indicate the current sort
column)?

* No x scrolling in treeview?

* Auto-ellipsing, or other detection on truncation for treeview?

* They do both have column and element visibility control.

* Any row/column spanning in treeview?

Except for the last one, the rest would all be desirable in the most =
generic
of directory browsers.  While it is certainly possible to address the =
above
issues, is there time to do it?  What about taking that time and working =
on
ttk::dialog, ttk::toplevel, ttk::menu, etc?

Jeff