Re: [Tile-dev] Tile compatibility policy and the core merge

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

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 <je...@ac...>=0ATo: Larry McVoy <lm...@bi...>; =
Joe English <jen...@fl...>=0ACc: tkt...@li...=
ge.net; Tim Baker <tre...@ho...>=0ASent: 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 lis...@li...=
forge.net=0Ahttps://lists.sourceforge.net/lists/listinfo/tktable-tile-dev=
=0A=0A=0A=0A=0A