Tk Source Code

There appears to be refresh problems when using current Aqua (Cocoa) Tk 8.5.x or 8.6.x builds on the newly released OS X 10.9. I first noticed the problem using Python IDLE (linked with a Tk 8.5.x) but the problem can be easily reproduced using a current Wish "Basic editable text" widget demo.

The following two screenshots demonstrate the problem.

https://www.dropbox.com/s/b517eq09x816d4h/tk85_15_mavericks_1.jpg

https://www.dropbox.com/s/6xe4hptm5e53tk5/tk85_15_mavericks_2.jpg

Clicking back and forth between the two Tk windows using the mouse, neither the window gaining focus nor the window losing focus gets updated properly. In the first, note the incomplete black border around the text widget: it was created by moving the mouse randomly over the border without hovering over the scroll bar on the right or without using the keyboard. In the second, note the incompletely highlight text and the misplaced text in the bottom border of the foreground window with focus and how the border is still displayed around the text field in the background window that no longer has focus. If the mouse is hovered over the scroll bar on the right or if the keyboard is used to enter a character, the windows are then updated properly.

Caveats: I have been unable to reproduce the problem with the Tcl/Tk 8.5.9 shipped by Apple in OS X 10.9. I can reproduce the problem with recent various versions of ActiveTcl 8.5.x and 8.6.x for OS X. And I can reproduce the problem with versions of 8.5.15 and 8.6.1 built from the release tarballs. I also discovered by accident that the problem appears to only happen when the Cocoa Tk is running in 64-bit mode (the default on 64-bit capable Macs), but not in 32-bit mode. This can be demonstrated using the ActiveTcl wish8.5 by forcing the execution architecture:

cd /Library/Frameworks/Tk.framework/Versions/8.5/Resources/Wish.app/Contents/MacOS
arch -x86_64 ./Wish  # text widget demo exhibits the problem
arch -i386 ./Wish  # no problem

This leads me to speculate that there might be some legacy 32-bit Carbon API being used that is skipped in 64-bit mode. Or perhaps there is simply some arch-related code bug. It might also be useful to examine what source and patches Apple uses for the system Tk 8.5. The 10.9 versions should eventually get published here: http://opensource.apple.com

Also, note that while the problem is reproducible on 10.9 with most versions of the Python IDLE application that link with a non-Apple Cocoa Tk 8.5, it is not reproducible by clicking on the IDLE.app icon of the current python.org 2.7 binary installer, e.g. the equivalent of:

open /Applications/Python\ 2.7/IDLE.app

For arcane reasons, that causes Tk to always be launched in 32-bit mode (that's how I discovered the dependency). The problem can be demonstrated by launching the same Python and IDLE via:

/Library/Frameworks/Python.framework/Versions/2.7/bin/idle2.7

http://www.python.org/download/releases/2.7.5/

http://www.activestate.com/activetcl/downloads

Current versions of Python 3.x IDLE.app launch in 64-bit mode and do show the problem with ActiveTcl 8.5 installed in /Library/Frameworks.

Daniel Steffen provided me a patch for this issue that he implemented against Apple's private branch of Tcl/Tk during the development of Mavericks: after applying it to trunk and 8.6, I no longer see problems with redraw on my installation of Mavericks. Therefore, I am closing this bug report with thanks to Ned for the report and to Daniel for the patch, which I have committed to trunk and core-8-5-branch.

Apple has now updated their opensource website to include 10.9 packages:

http://opensource.apple.com/source/tcl/tcl-102/

If I understand it correctly, it does confirm that they are still picking up the Tk 8.5 source from the obsolete github DAS backport and not from current source release tarballs or from Fossil.