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

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

So, I'm not following 100%. Are you saying when Tile goes into the core, we=
 will lose the treeview widget?=0A=0AThanks,=0A =0A--brett=0A=0A----- Origi=
nal Message ----=0AFrom: Joe English <jen...@fl...>=0ATo: tktable=
-til...@li...=0ASent: Saturday, November 18, 2006 12:18:2=
9 PM=0ASubject: [Tile-dev] Tile compatibility policy and the core merge=0A=
=0A=0A=0AWhen making incompatible changes to the Tile public API,=0AI've be=
en trying to follow a policy where the old and new=0Asyntaxes are both supp=
orted for at least one release cycle,=0Athen removing the old syntax at a l=
ater time.  This is to=0Aavoid the need for "flag day" conversions, where u=
sers have=0Ato upgrade all the programs that use Tile as soon as they=0Aupg=
rade Tile itself.=0A=0AAs it stands right now in Tk CVS HEAD, switching fro=
m=0ATk<=3D8.5a5+tile to Tk>=3D8.5a6 will require a flag day conversion.=0AS=
o the top priority for Tile 0.8.0 is to act as a transitional=0Arelease: it=
 should support the Tile 0.7.X interface as well=0Aas the ttk::* interface =
provided by the core.  That way=0Ausers who wish to do so can upgrade in tw=
o easier stages=0Ainstead of one hard one.=0A=0ATo make this work, the core=
 API will need a couple changes=0Aas well.=0A=0AFirst: the treeview widget =
needs to come back.  People are=0Aactually using this widget, and the only =
alternative I can think=0Aof is for them to switch to TkTreeCtrl.  Although=
 TkTreeCtrl can=0Acertainly do all the things that ttk::treeview can (and m=
uch,=0Amuch more!), it's not that easy to use; and since "ease of use"=0Ais=
 the primary, overriding design goal of the ttk::treeview=0Awidget, I don't=
 think this will be work upgrade strategy.=0A=0A(Jeff was talking about dro=
pping ttk::dialog, too.  That would=0Abe OK, since the implementation is al=
l in Tcl and can be=0Adistributed separately, but ttk::treeview can't be.)=
=0A=0ANext: Ttk_Init() in the core needs to [package provide $something].=
=0ARight now, if you load the tile package into an 8.5a6 core,=0Aall heck b=
reaks loose, and I don't know how to fix this yet.=0ASo existing code that =
says [package require tile] is going=0Ato suffer catastrophic failure unles=
s 8.5a6+ can make this=0Ainto a no-op, either by declaring "tile 0.8.0" alr=
eady=0Aprovided or by registering a do-nothing "ifneeded" script.=0A=0AThe =
stubs mechanism (needed for third-party themes like TileQT)=0Aalso uses the=
 package database, which is another reason for=0Athe core to [package provi=
de $something].  I can find a workaround=0Afor this if necessary, though.=
=0A=0AAnd on the subject of third-party themes: Tk 8.5 is definitely=0Agoin=
g to require a flag day conversion for them.  This isn't=0Aas big a deal --=
 there aren't as many themes as there are=0Aapplications using Tile, the ch=
anges required are minor and=0Amostly mechanical, and a flag day for themes=
 was on the=0ATile 0.8.X roadmap anyway.=0A=0AIt doesn't look like I'll be =
able to get the theme overhaul=0Adone in time for the December core release=
, so third party=0Atheme developers should expect two flag days.  Sorry abo=
ut=0Athat; the release schedules just aren't lined up right.=0A=0A=0A--Joe =
English=0A=0A  jen...@fl...=0A=0A--------------------------------=
-----------------------------------------=0ATake Surveys. Earn Cash. Influe=
nce 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 s=
urveys - and earn cash=0Ahttp://www.techsay.com/default.php?page=3Djoin.php=
&p=3Dsourceforge&CID=3DDEVDEV=0A___________________________________________=
____=0ATktable-tile-dev mailing lis...@li....n=
et=0Ahttps://lists.sourceforge.net/lists/listinfo/tktable-tile-dev=0A=0A=0A=
=0A=0A