See the document ''A Busy Developer's Guide to Tcl/Tk 8.5'' [http://www.markroseman.com/tcl/guide85.html] by [Mark Roseman]. This topic also came up on [comp.lang.tcl], initially in this thread [http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/278afed700e692c3/79283a297fda080b?lnk=raot#79283a297fda080b]. Some of the responses posted include: * Read [Changes in Tcl/Tk 8.5] * Scripts that depend on the exact behavior of cursor motion in the [text] widget may have problems. * Scripts that depend on details of font handling may have problems. * you're SOL if you're on Mac Classic. :-) * if you write scripts (or test suites!) that depend on formats of particular error messages coming from Tcl or Tk, you may have to change them. Various changes have been made to error messages. * If you use only tcl.h, tk.h and the exported functions from the stubs table you should be safe. ''(Ignore if you only code in Tcl, as opposed to Tcl+C.)'' * If you go from 8.4 to 8.5 it should be easy; simply recompile. ''(Ignore if you only code in Tcl, as opposed to Tcl+C.)'' * If you go from 8.x x <4 to 8.5 you may need to fix some reference to arguments which are not CONST (that changed in 8.4). (see [Migration to 8.4: CONSTification] ) ''(Ignore if you only code in Tcl, as opposed to Tcl+C.)'' * If you go from 7.x to 8.5 you can expect more work. * If you use tclInt.h or other nonpublic interfaces all bets are off...; try to recompile and see where the compiler bitches. ''(Ignore if you only code in Tcl, as opposed to Tcl+C.)'' * My very first test failed, trying xtem from http://www.ctan.org/tex-archive/support/xtem_texmenu/xtem/?action=/te... ====== I get (when pressing the exit button) bad variable name "geom(.xtemqd)": upvar won't create a scalar variable that looks like an array element while executing "global [set var]" (procedure "writeVarList2File" line 5) : (followed by more text that I won't quote) : ====== * Reply was: This statement used to be "useless": it would have created a variable that is completely unreachable from Tcl code. It is now an error. * If you were using the [dict] as an extension in 8.4, you may want to remove the ''package require dict'' since it is now built into 8.5. * There have been a number of significant upgrades for [dict]s in Tcl 8.5. * Integer operations no longer wrap around at 2^31 (or whatever value your platform dictates); make use of the int or wide functions, or bit masking, etc. to limit range explicitly if needed. * [tcl_precision] changed - where previously numbers might have displayed as 3.3, under 8.5 they may show as 3.30000000000003 for example. I had to fix this by adding additional trace commands and shadow variables to reformat the numbers. ''Concerns use with -textvariable and the like. Normally numbers presented to the user should have been explicitly [format]ed anyway.'' Previously, the default was tcl_precision of 12, but with the expanded floating point functionality, that variable's value now is set to 0. * [grid] behavior changed when the widget is smaller than the container. Tcl 8.5 added the [grid anchor] command but the 8.5 default is nw while 8.4 behavior was center. * Take a look at the entries in the "changes" files (included in the Tcl and Tk source code distributions) that are marked '''** POTENTIAL INCOMPATIBILITY **'''. * If you were using the [Tile] extension in tk 8.4, the functions were moved into the ttk [namespace]. * The autoconf for Tcl requires at least autoconf 2.57 to regenerate Tcl's `configure`. * read obsolete.tcl if you need to make use of ::tk::classic::restore to return to previous widget default widths, etc. * According to various reports, [MacOS 9], [IRIX] 4, [RISCos], [Ultrix] and ancient [BSD] systems are no longer supported by Tcl/Tk starting with 8.5. * [First impressions with tcl/tk 8.5.0] * [ActiveTcl] 8.5 on Unix is built with [thread]s enabled - use of this tclsh starts a base thread, which will cause conflicts if other code within the process uses [fork]. * Text widget now defaults to a fixed-width font (TkFixedFont vs MS Sans Serif) * With Tk 8.5, at configuration time, one has to choose either --enable-xft to get anti-aliased fonts or --disable-xft to get the old bitmap fonts. Under the X window system, at least, it is reported that you can only get one or the other. The result is that users may see a different set of fonts being displayed when using a Tk configured for the anti-aliased fonts, unless the machine in use has both bitmap and anti-alias fonts with the same font names. One developer reports that when his application ran under tk 8.5 with xft enabled, his [canvas] [postscript] output was no longer printing - because the fonts being selected from the canvas didn't match the fonts on his printer. ---- * Code using a list where a string is expected may find that under 8.5, the value that is included now is braced: ====== $ tclsh8.4 % list #123456 #123456 %^D $ tclsh8.5 % list #123456 {#123456} % ====== While from a Tcl point of view, the two are equivalent, there are coding situations where a string is needed. As always, in Tcl, be certain to specifically use strings and string functions when strings are required, and use list functions and lists where lists are required. '''[DGP]''' No, they are not equivalent. Tcl 8.4 is buggy. In Tcl 8.5, the bug has been fixed. See TIP 148 [http://tip.tcl.tk/148] for all the details. [PWQ] ''22 Aug 08'', So now when I print out a list of four colour names using #rrggbb notation I can always expect the first colour to be braced and then rest unbraced, thanks for that, that is so much better. I am always wanting to eval comments as lists and I never want to use #rrggbb colour names in lists. ---- Other wiki pages related to Tcl 8.5 differences * [Tcl/Tk 8.5: New public C routines] * [Changes in Tcl/Tk 8.5.1] * [Changes in Tcl/Tk 8.5.2] * [Changes in Tcl/Tk 8.5.3] * [First impressions with tcl/tk 8.5.0] * [Documentation and Demos for Tcl/Tk 8.5] ---- [LV] 2008-08-21 I have had several developers who have been trying to bring up their Tcl 8.4 applications using Tcl 8.5. While the applications are coming up, the number one complaint that I get is that widgets are coming up with different colors. The primary example I have seen is the code sample I added over on [iwidgets] while trying to figure out a problem in one of the widgets. Besides the problem with the button placement, under Tcl 8.4, the code there comes up with the listbox having a grey background, but under Tk 8.5 it has a white background. Is there something simple a developer can do to get this behavior reversed, other than changing lots of lines of code to hard code the color? [JH] Use '''tk::classic::restore''', although the new defaults are intended to be a strict improvement for modern UI conventions. This is not considered an incompatibility. ---- [LV] There is a minor different in [glob] in Tcl 8.5. I don't see it mentioned in the changes file and can't put my finger on any specific thing in the ChangeLogs for it. Basically, in Tcl 7.6 through 8.4, glob would ''normalize'' a path name, dropping the final slash of a directory name: === $ tclsh8.4 % glob /home/lwv27/ /home/lwv27 % ^D but now $ tclsh8.5 % glob /home/lwv27/ /home/lwv27/ % ^D === '''[DGP]''' Bug reports like this belong in the Tracker, not here. [LV] I don't know if I am convinced it is a bug report. It is certainly a difference in behavior, but I myself don't see it as a bug. This minor difference actually resulted in a bug report over on modules-interest@lists.sourceforge.net , where a function called listModules no longer works, because of the unexpected behavior. Look for the thread titled: recent TCL versions break "listModules" due to different "glob" behavior and result in // instead of / as directory-version separator. I suggested the person report it as a bug, and he was not comfortable doing so, indicating that it could very well be an intentional change. Based on your comment, I will indeed open a new ticket. Thank you. ---- [PWQ] ''22 Aug 08'', There have been numerous requests for changes to the core that are rejected out of hand because they would make break existing code. However it seems that when the TCT thinks that the change is ok then f*k the existing applications and carry on regardless. Why is it the Application developers burdon to change his code when the Core is Changed? This is all very well for the TCT members who just write 10 line toy examples. When you have 20,000 lines of code to look through and another how much more in other peoples tcl extensions that are no longer in developent, this is just bullshit. Hasnt the TCT learned from the 8.0-8.1 debarkle. The application developer has no control over which version of Tcl is installed by the end user. Can't the TCT put some forward planning into the changes. For example, if an application executes: package require Tcl 8.4 Then the init code for 8.5 automatically sources compatibility extensions to make the new interpreter function the same as the old 8.4 version. If this means some optimisations and special features are turned of , so be it. The application developer can then choose to upgrade/modify and now has time to adapt the code for these incompatibe changes. [DKF]: The main reason we don't do that is because it is very difficult! When something subtle is changed, it's very hard to evaluate how much third-party code is affected since much code isn't available for public grepping and it's usually not possible to figure out what to search for anyway. And with the subtle stuff, it's often extremely difficult to do code to make things exactly compatible with previous versions (the grossly different stuff such as any extra commands are much simpler; old code should just ignore them). An example of this sort of subtlety is the changes to the font system on X11; it's been terrible for ages (really!) and so we finally got an improvement in to make things get up to the level of support that other platforms had been enjoying for a long time. Unfortunately, it changes what sets of fonts are supported by a system (that's totally outside our control, BTW) and that in turn hits a lot of GUI apps which were tuned to work around the horrible-ness, and which font system is used is a build-time option for Tk. Similarly, the new ttk widgets aren't drop-in replacements for the old tk ones (and can't be; they're different in detail) so upgrading from old Tk widgets to new Ttk ones depends heavily on the degree of change needed. Unfortunately, it seems that many production Tk apps did heavy tweaking of widget options and as such, face quite a lot of pain going to the new widgets where everything is theme/style based; by contrast, toy scripts mostly "just work". I don't intend to apologize for this, especially as we kept the old widgets around so code can Just Work for the most part. If you want to discuss the details of downgrading on `[[package require Tcl 8.4]]`, talk to [DGP]; his understanding of the issues is more profound than mine. ---- !!!!!! %| [Category Documentation] |% !!!!!!