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

[Will D. <Wil...@jp...>]

Jeff,

This is exactly my point--there are uses for a tree widget that
do *not* resemble a rich multicolumn listbox.

Will

On Nov 22, 2006, at 8:42 AM, Jeff Hobbs wrote:

> 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
>
>
> ----------------------------------------------------------------------- 
> --
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Tktable-tile-dev mailing list
> Tkt...@li...
> https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
>
>
------------------------------------------------------------------------
Will Duquette, JPL  | Wil...@jp...
But I speak only    | http://eis.jpl.nasa.gov/~will (JPL Use Only)
for myself.         | It's amazing what you can do with the right tools.