TkTable / Tile / Vu

Jeff Hobbs wrote:
>
> Brett Schwarz wrote:
>> I like the idea of waiting for 8.6 to get a good solution for
>> a tree widget in the core (whether that's an enhanced
>> treeview or a wrangled up tktreectrl). Even though I would
>> have loved to see it part of 8.5, I'd rather wait for a good
>> and solid solution.
>
> That would address the situation *if* we felt that treectrl served as a 
> useful
> base for "more generic" treeview widget.  That is what I am not certain 
> of.
>
> I did verify that Tim's latest changes greatly reduce memory (ActivePerl 
> PPM
> steady state reduced from ~66MB to ~43MB, with just an upgrade to treectrl
> 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.

> (BTW Tim - I had to modify the configure.ac to kick treectrl to 2.2 - any
> reason not to commit that?)

Done.

-- Tim Baker

I like the idea of waiting for 8.6 to get a good solution for a tree widget=
 in the core (whether that's an enhanced treeview or a wrangled up tktreect=
rl). Even though I would have loved to see it part of 8.5, I'd rather wait =
for a good and solid solution.=0A=0A=0A=0A----- Original Message ----=0AFro=
m: Jeff Hobbs <jeffh@...: Larry McVoy <lm@...>; =
Joe English <jenglish@...: tktable-tile-dev@...=
ge.net; Tim Baker <treectrl@...: Monday, November 20, 2006 =
11:38:07 AM=0ASubject: Re: [Tile-dev] Tile compatibility policy and the cor=
e merge=0A=0ALarry McVoy wrote:=0A> > First: the treeview widget needs to c=
ome back.  People are actually =0A> > using this widget, and the only alter=
native I can think of is for them =0A> > to switch to TkTreeCtrl.  Although=
 TkTreeCtrl can certainly do all the =0A> > things that ttk::treeview can (=
and much, much more!), it's not that =0A> > easy to use; and since "ease of=
 use" is the primary, overriding design =0A> > goal of the ttk::treeview wi=
dget, I don't think this will be work =0A> > upgrade strategy.=0A> =0A> Has=
 anyone considered the idea of wrapping the treeview =0A> widget API around=
 TkTreeCtrl?  From what I can see, the =0A> advantage of treeview is that i=
t is pretty easy to use and =0A> the advantage of TkTreeCtrl is that it is =
powerful but =0A> complex.  Seems like a simplistic API that offers a "kind=
er =0A> and gentler" introduction to TkTreeCtrl is perhaps a more =0A> stra=
tegic approach than maintaining two code bases.=0A=0AI have considered this=
, but there is simply not enough time to definitively=0Asay which is the be=
st way to go for 8.5.  treeview has some "deficiencies",=0Abut that may jus=
t be my view of greater expectations from tree widgets.  I=0Aknow that Joe =
has done a good deal of work on this, and I really intend no=0Apersonal aff=
ront.  I want to look at it from an objective core future=0Aperspective.=0A=
=0AI use treectrl a lot, but there certainly is not enough time to wrangle =
it=0Ainto "core status" for 8.5.  Furthermore, Tim is continuing to work on=
 it.=0AI'd like us to consider this again for 8.6 though (along with tktabl=
e).  One=0Aof the current issues with treectrl is that it is a memory pig (=
notably more=0Athan I expect should be necessary for some views), but I exp=
ect some API=0Achanges (possibly compatible) would be in order as well.=0A=
=0Atreectrl also does a ton more than a simple treeview requires.  Useful f=
or=0Asome apps, but a multi-column list is really important by itself.  tre=
eview is=0Anice, but it lacks functionality that others may find useful hav=
ing come to=0Aexpect them in packages like tablelist and bwidget's tree.  t=
reeview's=0Ainclusion in the core will hamper any rapid improvements (that =
of course=0Adepends on how objectionable others will be to feature improvem=
ents in=0Apatchlevel releases).=0A=0AAs you may see, I'm currently still si=
tting on the fence on this one.=0A=0AJeff=0A=0A=0A-------------------------=
------------------------------------------------=0ATake Surveys. Earn Cash.=
 Influence the Future of IT=0AJoin SourceForge.net's Techsay panel and you'=
ll get the chance to share your=0Aopinions on IT & business topics through =
brief surveys - and earn cash=0Ahttp://www.techsay.com/default.php?page=3Dj=
oin.php&p=3Dsourceforge&CID=3DDEVDEV=0A____________________________________=
___________=0ATktable-tile-dev mailing list=0ATktable-tile-dev@...=
forge.net=0Ahttps://lists.sourceforge.net/lists/listinfo/tktable-tile-dev=
=0A=0A=0A=0A=0A

Jeff Hobbs wrote:
> (that of course
> depends on how objectionable others will be to feature improvements in
> patchlevel releases).

If we put some large warnings in the documentation, I think we can get
away with it. If we can simultaneously arrange for at least basic common
usage (i.e. for people who don't tweak stuff) to remain the same, so
much the better.

Donal (I can remember the Tk 8.4 panedwindow had some horrible bugs that
        made it unusable until quite far into the 8.4 release cycle, so a
        new widget not being 100% baked wouldn't be unprecedented.)