Menu
▾
▴
tktable-tile-dev
|
From: Joe E. <jen...@fl...> - 2006-11-18 20:18:32
|
When making incompatible changes to the Tile public API, I've been trying to follow a policy where the old and new syntaxes are both supported for at least one release cycle, then removing the old syntax at a later time. This is to avoid the need for "flag day" conversions, where users have to upgrade all the programs that use Tile as soon as they upgrade Tile itself. As it stands right now in Tk CVS HEAD, switching from Tk<=8.5a5+tile to Tk>=8.5a6 will require a flag day conversion. So the top priority for Tile 0.8.0 is to act as a transitional release: it should support the Tile 0.7.X interface as well as the ttk::* interface provided by the core. That way users who wish to do so can upgrade in two easier stages instead of one hard one. To make this work, the core API will need a couple changes as well. First: the treeview widget needs to come back. People are actually using this widget, and the only alternative I can think of is for them to switch to TkTreeCtrl. Although TkTreeCtrl can certainly do all the things that ttk::treeview can (and much, much more!), it's not that easy to use; and since "ease of use" is the primary, overriding design goal of the ttk::treeview widget, I don't think this will be work upgrade strategy. (Jeff was talking about dropping ttk::dialog, too. That would be OK, since the implementation is all in Tcl and can be distributed separately, but ttk::treeview can't be.) Next: Ttk_Init() in the core needs to [package provide $something]. Right now, if you load the tile package into an 8.5a6 core, all heck breaks loose, and I don't know how to fix this yet. So existing code that says [package require tile] is going to suffer catastrophic failure unless 8.5a6+ can make this into a no-op, either by declaring "tile 0.8.0" already provided or by registering a do-nothing "ifneeded" script. The stubs mechanism (needed for third-party themes like TileQT) also uses the package database, which is another reason for the core to [package provide $something]. I can find a workaround for this if necessary, though. And on the subject of third-party themes: Tk 8.5 is definitely going to require a flag day conversion for them. This isn't as big a deal -- there aren't as many themes as there are applications using Tile, the changes required are minor and mostly mechanical, and a flag day for themes was on the Tile 0.8.X roadmap anyway. It doesn't look like I'll be able to get the theme overhaul done in time for the December core release, so third party theme developers should expect two flag days. Sorry about that; the release schedules just aren't lined up right. --Joe English jen...@fl... |
|
From: Kevin W. <kw...@co...> - 2006-11-18 21:22:20
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joe English wrote: > > When making incompatible changes to the Tile public API, > I've been trying to follow a policy where the old and new > syntaxes are both supported for at least one release cycle, > then removing the old syntax at a later time. This is to > avoid the need for "flag day" conversions, where users have > to upgrade all the programs that use Tile as soon as they > upgrade Tile itself. > > As it stands right now in Tk CVS HEAD, switching from > Tk<=8.5a5+tile to Tk>=8.5a6 will require a flag day conversion. > So the top priority for Tile 0.8.0 is to act as a transitional > release: it should support the Tile 0.7.X interface as well > as the ttk::* interface provided by the core. That way > users who wish to do so can upgrade in two easier stages > instead of one hard one. > I'm not clear on what changes will need to be made to my code when Tile goes into the core. Currently I use "package require tile" and the ttk:: namespace to set up my widgets. What will I need to do differently when I start using Tk 8.5? - -- Kevin Walzer Code by Kevin http://www.codebykevin.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFX3lvEsLm8HXyq4sRAtA5AJ9Yi22xyoo3dDwRPkb0JAXc6J2EPQCeI5sm 68GZfu/uTCRZ42Y06Utm/f4= =ncWi -----END PGP SIGNATURE----- |
|
From: Joe E. <jen...@fl...> - 2006-11-18 21:38:02
|
Kevin Walzer wrote: > > I'm not clear on what changes will need to be made to my code when Tile > goes into the core. Currently I use "package require tile" and the ttk:: > namespace to set up my widgets. What will I need to do differently when > I start using Tk 8.5? For application code, hopefully very little :-) As mentioned earlier, [ttk::paned] has been renamed to [ttk::panedwindow]. If you're using 0.7.8 you can change that right now, since [ttk::panedwindow] is available as a forward-compatibility alias. [style] has been renamed to [ttk::style]. Tile 0.7.8 doesn't have a forward-compat alias for this one since I didn't know this was going to happen. The ttk::treeview widget might not be there. Other changes: tile::availableThemes -> ttk::themes, and tile::setTheme -> ttk::setTheme. Everything else in the tile::* namespace is gone (none of that was public anyway, though). At the moment, in Tk CVS HEAD, calling "package require tile" in an 8.5a6 interp will break badly. This needs to be fixed before 8.5 beta. For themes and custom widgets, there might be more changes. --Joe English jen...@fl... |
|
From: Jeff H. <je...@ac...> - 2006-11-20 19:01:59
|
> Other changes: tile::availableThemes -> ttk::themes, > and tile::setTheme -> ttk::setTheme. Everything else > in the tile::* namespace is gone (none of that was > public anyway, though). >=20 > At the moment, in Tk CVS HEAD, calling "package require tile"=20 > in an 8.5a6 interp will break badly. This needs to be fixed=20 > before 8.5 beta. >=20 > For themes and custom widgets, there might be more changes. It seems that the current major blocker is that the ttk::theme::default versions differ (and an error is thrown on the different version = provide), and then that the named font TkClassicDefaultFont already exists. Putting a catch around those 2 statements allows for tile to be package required into 8.5. I don't see any reason not to commit those changes = ... Jeff |
|
From: Joe E. <jen...@fl...> - 2006-11-23 17:04:47
|
Jeff Hobbs wrote: > > [Joe English] > > At the moment, in Tk CVS HEAD, calling "package require tile" > > in an 8.5a6 interp will break badly. This needs to be fixed > > before 8.5 beta. > > [...] > > It seems that the current major blocker is that the ttk::theme::default > versions differ (and an error is thrown on the different version provide), an > then that the named font TkClassicDefaultFont already exists. > > Putting a catch around those 2 statements allows for tile to be package > required into 8.5. I don't see any reason not to commit those changes ... That isn't the main problem. The main problem is that when tile.so's copy of Ttk_Init() gets called, it replaces the core's copy of the interp-specific data and other internal data structures. This stuff doesn't expect to get deleted until the interp is destroyed; who knows what will happen? I *think* that as long as the app calls [package require tile] before creating any ttk::* widgets, this will be harmless, but I won't swear to it. Another issue that isn't an immediate problem but will become much more severe in the long term is that on ELF-based systems (e.g., most Unixes), most of the entry points in tile.so get resolved to the core's copy instead of tile's. This doesn't hurt today, since both routines are identical at the moment, but down the road it will become a big problem as the internals evolve and diverge. Tk 8.5 apps that call [package require tile] will crash and burn in unpredictable ways if the wrong version of the tile package happens to be lying around on the system. I'd really like to avoid this: putting Ttk into the core was supposed to make deployment easier, and this is a potential landmine field. . . . Re: TkClassicDefaultFont -- this should probably just be removed. It makes the "classic" theme look like 8.4 on X11, but it's a mismatch on Windows, OSX, and X11+Xft. (Plus it creates an extra named font that's almost never used.) And re: ttk::theme::default -- more on that later. --Joe English |
|
From: <lm...@bi...> - 2006-11-19 17:38:23
|
> First: the treeview widget needs to come back. People are > actually using this widget, and the only alternative I can think > of is for them to switch to TkTreeCtrl. Although TkTreeCtrl can > certainly do all the things that ttk::treeview can (and much, > much more!), it's not that easy to use; and since "ease of use" > is the primary, overriding design goal of the ttk::treeview > widget, I don't think this will be work upgrade strategy. Has anyone considered the idea of wrapping the treeview widget API around TkTreeCtrl? From what I can see, the advantage of treeview is that it is pretty easy to use and the advantage of TkTreeCtrl is that it is powerful but complex. Seems like a simplistic API that offers a "kinder and gentler" introduction to TkTreeCtrl is perhaps a more strategic approach than maintaining two code bases. Comments? -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com |
|
From: Jeff H. <je...@ac...> - 2006-11-20 19:39:36
|
Larry McVoy wrote: > > First: the treeview widget needs to come back. People are actually=20 > > using this widget, and the only alternative I can think of is for = them=20 > > to switch to TkTreeCtrl. Although TkTreeCtrl can certainly do all = the=20 > > things that ttk::treeview can (and much, much more!), it's not that=20 > > easy to use; and since "ease of use" is the primary, overriding = design=20 > > goal of the ttk::treeview widget, I don't think this will be work=20 > > upgrade strategy. >=20 > Has anyone considered the idea of wrapping the treeview=20 > widget API around TkTreeCtrl? From what I can see, the=20 > advantage of treeview is that it is pretty easy to use and=20 > the advantage of TkTreeCtrl is that it is powerful but=20 > complex. Seems like a simplistic API that offers a "kinder=20 > and gentler" introduction to TkTreeCtrl is perhaps a more=20 > strategic approach than maintaining two code bases. I have considered this, but there is simply not enough time to = definitively say which is the best way to go for 8.5. treeview has some = "deficiencies", but that may just be my view of greater expectations from tree widgets. = I know that Joe has done a good deal of work on this, and I really intend = no personal affront. I want to look at it from an objective core future perspective. I use treectrl a lot, but there certainly is not enough time to wrangle = it into "core status" for 8.5. Furthermore, Tim is continuing to work on = it. I'd like us to consider this again for 8.6 though (along with tktable). = One of the current issues with treectrl is that it is a memory pig (notably = more than I expect should be necessary for some views), but I expect some API changes (possibly compatible) would be in order as well. treectrl also does a ton more than a simple treeview requires. Useful = for some apps, but a multi-column list is really important by itself. = treeview is nice, but it lacks functionality that others may find useful having come = to expect them in packages like tablelist and bwidget's tree. treeview's inclusion in the core will hamper any rapid improvements (that of course depends on how objectionable others will be to feature improvements in patchlevel releases). As you may see, I'm currently still sitting on the fence on this one. Jeff |
|
From: Donal K. F. <don...@ma...> - 2006-11-21 09:54:55
|
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.)
|
|
From: Jeff H. <je...@ac...> - 2006-11-21 17:29:37
|
Donal K. Fellows wrote: > 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. Also note that we should allow ourselves to take advatange of the fact that 8.5+ will be require-able by specific patchlevel (yeah!). Jeff |
|
From: Joe E. <jen...@fl...> - 2006-11-23 17:47:45
|
[ Followups to tcl...@li... ] On tktable-tile-dev, Jeff Hobbs wrote: > > [...] treeview's > inclusion in the core will hamper any rapid improvements (that of course > depends on how objectionable others will be to feature improvements in > patchlevel releases). This might merit further discussion. (It pertains to Tile as a whole, not just the ttk::treeview widget). Although having merged Tile into the core has certainly slowed down development (well, that plus work and real life), it was never my intention to *stop* development on Tile. There are still a lot of improvements to be made, including new features and backward-incompatible changes. TIP#248 only said, in essence, "Put Tile into the core", but it was silent on the subject of future maintenance. Was the intent to take a snapshot and then tether ttk::* evolution to the core's release schedule, strict compatibility policies and all, or will feature changes in core patchlevel releases be allowed? (My take: Tile development can be arranged to accomodate the core's release schedule, but I don't think that shackling it with the core's compatibility policy is in anyone's best interest at this point.) --Joe English jen...@fl... |
