Re: [Tile-dev] a tale of 2 trees

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

Will,

Your points are in general correct, but overlook the direct remarks I 
made below.  Those features are certainly required for a decent dir 
browser, but they are necessary for many other type of apps as well. 
The lack of these in treeview is why people have turned to pure Tcl 
alternatives even when treeview was available.  If you want to look at 
treeview as a multicolumn listbox, then it really fails in 2 areas - no 
x scrolling and the inability to control stretch/shrink of columns.  Joe 
has said he likely won't have the time to address these before 8.5.0, 
and thus I don't think it serves the core much to distract with the 
treeview.

Jeff

Will Duquette wrote:
> Jeff,
> 
> You keep talking about directory browsing, which is an application
> for which a tree is useful but which involves considerably more than
> basic tree behavior.  treectrl supports this, and treeview doesn't.
> 
> I think the basic problem here is that although both widgets have
> "tree" in their name, treectrl *isn't* a "tree" widget.  You can use
> it for that; but it's really something more powerful, and perhaps should
> have a name that indicates that.
> 
> Frankly, I can see a place in Tk/Ttk for both widgets.  A simple one,
> akin to the standard Tk listbox, and a complex but vastly more powerful
> one.
> 
> Will
> 
> On Nov 21, 2006, at 4:02 PM, Jeff Hobbs wrote:
> 
>> Tim Baker wrote:
>>> Jeff Hobbs wrote:
>>>> 2.2).  However, if I only needed what a "simpler" treeview would 
>>>> provide,
>>>> and
>>>> it provided it with a memory size of ~20MB for the same app ... does 
>>>> that
>>>> 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
>>>> get treeview in 8.5, and treectrl in 8.6.
>>>
>>> Is it only the [style] and [element] commands that blows
>>> treectrl out of the "simple" space into "mega-configurable"?
>>> The high memory requirements are mostly a result of styles
>>> and elements. Whenever people comment that treectrl
>>> is difficult to use I start brainstorming alternate APIs. It
>>> 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