RE: [Tile-dev] Tree widget API

[Brett S. <bre...@ya...>]

--- Jeff Hobbs <je...@Ac...> wrote:

> > > It's only fault is the complexity of the API. 
> Is this unavoidable due 
> > > to the complexity of the widget, or is this
> something that post-dev 
> > > experience and more use with the widget can help
> to rationalize?
> > 
> >     I'm playing with it now to try and answer some
> of those 
> > questions, but someone else with more experience
> with the 
> > widget might be able to better answer them.  You
> seem to have 
> > worked with it a little, Jeff. 
> > Any initial musings you'd like to share?
> 
> > PS:
> > treectrl.n     108k
> 
> text.n:    78K
> canvas.n:  73K
> tktable.n: 60K.
> 
> Are those hard to understand?  Well, for some, but
> eventually
> you work through it all.  I think at least the
> treectrl docs
> are mostly complete, even if a few more samples
> might help
> explain things.
> 
> As for initial impressions, it has some elements of
> the canvas
> without using the same naming conventions.  It gets
> a bit
> blurry if you add tile with its new naming
> conventions into
> the mix, as treectrl has "elements" and "styles". 
> It's kind
> of Tix like in some respects.  Tim may be the best
> person to
> answer that.
> 

I kind of liked the suggestion previously stated on a
different thread (I think CLT maybe)...I think it was
Bryan. Create wrappers around tktreectrl for different
widgets; i.e. create a wrapper widget for a
multi-column widget, create a wrapper for a Tree
widget, etc. This could all be done in Tcl (I think).
Of course, you would still have the original
tktreectrl widget, for those non common uses.

I'm not saying we should not try to enhance the API.
We should (if needed). But, if I just need a Tree
widget, I don't want to monkey around configuring it
to act like a Tree widget, every time I need a Tree
widget.

my $0.02

    --brett