http://www.apple.com/macosx/ is the latest operating system from Apple, which has BSD Unix (approximately) as its underlying core, and a very nice GUI on top of it, known informally as "Aqua". Apple itself seems to be consistent in punctuating the label as "Mac OS X".
Tk runs natively on MacOS X, using an Aqua look and feel. This page is a summary of MacOS X specific issues. You can also compile and run an X-windows version of Tk under any X-windows client (X11 that Apple provides, DarwinX, XonX, etc), using whatever motif-like look and feel those toolkits provide. This page is primarily about the Aqua version.
http://cvs.sf.net/cgi-bin/viewcvs.cgi/*checkout*/tktoolkit/tk/macosx/README is the URL to the tk/macosx/README file , which is, according to Daniel Steffen, "probably the most complete reference at present" for OS X and Tcl.
Daniel Steffen has a very extensive Batteries Included release available: TclTkAquaBI (superset of ActiveTcl on other platforms). Alphatk used to be bundled with Tcl, Tk, but now embeds them.
Wish comes as an application (Wish.app) and two frameworks: Tcl.framework, Tk.framework. These must be installed in /Library/Frameworks or ~/Library/Frameworks.
As of October 2002, Tcl is very mature on MacOS X, but the Aqua-Tk release is less mature than the releases on other platforms (this is still true in January 2004). This means it still contains some bugs which everyone is encouraged to report/fix. As problems are fixed, this page will be updated accordingly. Please note that the tools required to build TkAqua are free from Apple and that it is very easy to build. It is also pretty easy to get the most recent sources from cvs, so you can get all the latest fixes quickly and easily, yourself:
See Steps to build Tcl/Tk 8.4.0 on MacOS X.
Patches outstanding:
Approximate list of bugs:
Issues fixed in cvs (but which may not be in a distributed binary release).
Outstanding Bugs/Issues as of last change to this page:
Issues to be aware of, which may or may not be bugs:
As ever, the source code is available, so everyone is welcome to contribute.
There are some other issues I'm personally having trouble verbalizing (perhaps because I haven't yet investigated them much). For instance, Bryan Oakley's combobox doesn't behave quite the same with respect to keyboard traversal. And there seems to be some issues with packing and/or gridding, but I'm not sure what that is. I see it when I run tkdiff[*] on the mac -- some buttons don't seem to expand properly (ie: checkbuttons that look just great on windows and unix appear too short, which causes the text to wrap and the buttons to be illegible). Maybe this goes back to checkbuttons wanting to wrap rather than take as much horizontal space as possible, but I haven't yet been able to duplicate this easily.
Vince adds: I think this is a bug in which the 'winfo reqwidth' of a checkbutton returns the reqwidth of the text, but doesn't add on the width of the checkbox bit. Does that make sense?
Tkdiff also shows another anomolie I haven't yet tracked down. In it's default mode, buttons in the toolbar appear with the text behind the image. The code was originally constructed to assume if you turn images on, the text gets turned off. It could be a bug in tkdiff, but the bottom line is that the mac version is different than on unix and windows.
Vince It shouldn't show both unless you have '-compound', and shouldn't put them on top of each other unless there is '-compound center', so I imagine this is a bug.
[*] the version of tkdiff available from accurev has a bug which prevents it from being run on 8.4, but it's an easy fix. There are a couple places that do "-pad 4" when it should be "-padx 4".
Old problems which have been fixed and appear in a binary release (since July 9th):
28sep02 jcw - Wish can be opened with the "open" command from the command line, but the only way to pass it cmdline-args seems to be to type:
<path_to_Wish.app_dir>/Contents/MacOS/Wish\ Shell arg1 arg2 ...
Also note that a script cannot yet be dropped on Wish to launch it.
8feb03 UKo - but now the 8.4.1 wish can be choosen as starting application for files with tcl-extension
03oct02 - jcw - Another tip from Jim Ingham: if a file is called "blah.command" (say a shell script), then double-clicking it brings up a Terminal window and runs the command in it (at least on 10.2). This does not seem to work when it's a symlink, so better make a copy (or a hard link, I s'pose).
3mar03 - Daniel Steffen - My Launcher [L1 ] utility helps with this (included with TclTkAquaBI or available separately).
18dec02 - Benny Riefenstahl - The 'problem' with the env array is generic to MacOSX/Aqua. On all Unixes the environment variables are set in shell scripts like ~/.profile, ~/.cshrc or similar. On Aqua the Finder is the login shell, it inherits its environment from the loginwindow application and that can be configured in ~/.MacOSX/environment.plist, see Apple Technote at [L2 ].
A recent question on comp.lang.tcl was asking how one sets up Tcl/Tk Aqua on MacOS X so that a Tcl/Tk script could be double clicked and launch appropriately.
08feb03 UKo The current 8.4.1 Wish is able to respond to the "open" Apple Event and can thus be choosen as application for opening files with the tcl-extension. For older versions (and the last tclkit that runs on non-Jaguar) one can make a applescript like this to start a specific tcl-script or startkit -- here my applescript for starting the local wikit copy:
do shell script "tclkit ~/bin/wikit.kit ~/bin/wikit.tkd"
(be sure to use the POSIX pathnames!)
And here a script that starts a tclkit for every file that is dropped on the script:
on open names repeat with kit in names set command to "tclkit " & (POSIX path of kit as string) & "" -- ignoring application responses do shell script command -- end ignoring end repeat return end open
save this from the applescript editor as program and the you can choose it as open application for any starkit or just drag'n'drop the kit onto the script -- voila.
TODO unfortunately the applescript and the tclkit will both be open -- I don't know how tho make the applescript finish and the tclkit keep on running. (as far as I understand this should be done with the "ignoring" statement -- but it doesn't work for me)
3mar03 - Daniel Steffen - It's probably easier to use my Launcher [L3 ] utility for this (included with TclTkAquaBI or available separately).
Apparently it's important for those working with MacOS X to know about fink, which provides the user the ability to keep installed packages up to date.
No - it's not important to know about fink - the standard MacOSX developer tools are quite sufficient. However, if you want to have a "Debian Linux-like" environment under MacOSX then fink will be of interest. I had fink installed but removed it ... it's fine in what it does but I prefer to work with the Apple tools as far as I can - stevel Feb 9, 2003
Apple have released a public beta of their X11 for MacOS X.
Even though it is still a beta, it runs the X11 version of Tclkit quite well. It is nicely integrated with Aqua and seems a lot faster than the older OroborOSx based X11 solution.
For more info see [L4 ] - stevel Feb 9, 2003
2003Sep18: On the Mactcl mailing list, Jim Ingram and Kevan Hashemi were discussing what was needed when writing a dynamically loadable extension for MacOS X. Kevan discovered that:
gcc -c ${INCL} lwdaq.c -o lwdaq.o \ -I/library/frameworks/tk.framework/headers \ -I/library/frameworks/tcl.framework/headers gcc -dynamiclib -o Lwdaq.dylib -framework Tcl -framework Tk lwdaq.o
for his C code resulted in code that is loadable.
2003 Oct 28: On the Mactcl mailing list, Kevan Hasemi and Daniel A. STeffen answer the question What do I need to do to get a development environment on a MacOS X machine?
Jason Tang Macs with a Panther install CD/DVD instead must use that disc to run the supplementary applications installer. From there install development tools. Now go to /Applications/Utilities/Installer and run the development tools installer.
DS goes on to say:
for TEA based extensions, the following configure invocation should do the trick:
.configure \ --prefix=/usr/local --libdir=/Library/Tcl \ --with-tcl=/Library/Frameworks/Tcl.framework \ --with-tclinclude=/Library/Frameworks/Tcl.framework/Headers \ --with-tk=/Library/Frameworks/Tk.framework \ --with-tkinclude=/Library/Frameworks/Tk.framework/Headers \ --enable-threads
You should probably link with stub libraries like on other unix platforms:
gcc -dynamiclib -o yourdylib.dylib yourcommands.o \ -L /Library/Frameworks/Tcl.framework/ -ltclstub8.4 \ -L /Library/Frameworks/Tk.framework -ltkstub8.4
You can build tcl & tk with X11 yourself in the standard unix manner and install into e.g. /usr/local and not bother with the framework based TkAqua.
You'll need X11 & X11SDK from Apple:
http://www.apple.com/macosx/features/x11/download/
Others working with MacOS X include William Duquette, Jeffrey Hobbs, Cameron Laird, Steve Landers, Bryan Oakley, and Jean-Claude Wippler.
LES on Feb 13, 2004: I was wondering how different MacOS X and Darwin are. I know Tcl/Tk run on both, but is it the same Tcl/Tk or are different ports required for each one?
MKS on Monday, 31 May 2004: Thanks to the help of Benjamin Riefenstahl, I was able to put together a means of having Aqua and X11 installations of Tcl/Tk coexist on the same machine, sharing packages where possible. I compiled the 'unix' codebase and installed it in /usr/local with:
cd $tclsource/unix ./configure --prefix=/usr/loca/ --enable-threads && make && make install cd $tksource/unix !-2
Then installed the "Batteries Included" binary release of the Aqua version.
To make the two versions share packages, I added the following to my ~/.tclshrc:
proc auto_path_handler {} { set ::auto_path_x11 [list /usr/local/lib/tcl8.4 /usr/local/lib] set ::tcl_pkgPath_x11 [list /usr/local/lib] set ::auto_path_aqua [list \ /Library/Frameworks/Tcl.framework/Versions/8.4/Resources/Scripts \ /Library/Frameworks/Tcl.framework/Versions/8.4/Resources \ /usr/lib ~/Library/Tcl /Library/Tcl /Network/Library/Tcl \ /System/Library/Tcl ~/Library/Frameworks /Library/Frameworks \ /Network/Library/Frameworks /System/Library/Frameworks] set ::tcl_pkgPath_aqua [list \ /Library/Frameworks/Tcl.framework/Versions/8.4/Resources/Scripts \ ~/Library/Tcl /Library/Tcl /Network/Library/Tcl /System/Library/Tcl \ ~/Library/Frameworks /Library/Frameworks /Network/Library/Frameworks \ /System/Library/Frameworks] # if the path to the executable contains /local, then it is the X11 # installation, otherwise it is the Aqua installation: if {(([regexp {/local} $::argv0]) || ([regexp {/local} [info nameofexecutable]]))} { set ::auto_path [concat $::auto_path_x11 $::auto_path_aqua] set ::tcl_pkgPath [concat $::tcl_pkgPath_x11 $::tcl_pkgPath_aqua] } else { set ::auto_path [concat $::auto_path_aqua $::auto_path_x11] set ::tcl_pkgPath [concat $::tcl_pkgPath_aqua $::tcl_pkgPath_x11] } return "" } auto_path_handler
These directories are specific to my installation. The best way to determine what yours should be is to start up both tclsh executables and copy out the values given for auto_path and tcl_pkgPath.
This has the effect of allowing package inclusion to search the appropriate location first for either given release, based on which binary is run.
Note X11 and Aqua CANNOT share Graphical packages (though the tclsh that ships with Aqua can load the X11 Tk, and thereafter use X11). In the event that an Aqua binary tries to require a package that is only present in the X11 tree (or vice versa) bad things may happen.
MAK (26 Oct 2004) - Building Embedded Tcl/Tk Aqua Applications in XCode
I had a world of trouble getting my application with embedded Tcl/Tk, that runs on Windows and Unix platforms, to build right for MacOS X. I think I've finally got it working, and I'm not sure exactly which combination of umpteen permutations it took, but perhaps this information will help a little bit.
The main problem I had is that the application would compile with my usual configure/makefile scripts, but it wouldn't run from the Finder - it would start and exit immediately. It would, however, run if I launched it by typing the executable name from the command line. This turned out to be because it needs to be wrapped in a .app (Application) bundle.
Application bundles are basically a special directory structure, with the top of the directory named *.app, with an XML file named Info.plist that describes the contents of the bundle. In the Finder they act like a single file, but from the command line act like a the regular directory they are.
As far as I know, there's no command-line tool provided to build such bundle, other than manually creating each of the directories and copying the appropriate files into the appropriate places, which is a bit of a pain if you're not familiar with the layout and the .plist DTD. So I set about trying to build it in XCode, which will take care of creating the bundle for you with the appropriate target type. Once the XCode project is set up you should be able to (theoretically) use "xcodebuild <projectfile>" to build from the command line outside the IDE, which, while still yet-another-build-system to go along with my configure/makefiles for *nix and VC++ project files for Windows, I figured was at least better than nothing.
I ran into a ton of headaches with XCode. Some of them bugs, some of them super-annoying limitations, but most of them out of scope for this little journal (e.g., you don't need to know about my headaches with the Rules system if you're not using generated source code). At any rate, the logical choice seemed to me to be to use the "Carbon Application" target for my application, given that Wish uses Carbon for the Aqua native stuff. Seems logical, right?
Couldn't get it to work. The first thing you'll run into if you do that is that you need to add -DMAC_TCL to the Extra CFLAGS setting to avoid naming conflicts for "Cursor" between Xlib.h and Carbon. Then you'll probably find that it can't find ConditionalMacros.h, which seems to be part of the Core Foundation, but it doesn't find it even if you add that framework. I might have gotten it to work if I manually added a bunch of header files to the project that I shouldn't (as opposed to just the frameworks), but I was getting tired of trying that (there and with other things involved in my particular application) and finding other problems and my project turning into more and more of a mess.
After poking around the Wish project trying to figure out just what the heck was so different, I noticed it had a regular target icon, instead of the "A" application icon. So I tried building using the "Legacy Application" target instead. That seemed to build quite easily, and work! Unfortunately, that target won't let you edit information like the name of the application's icon file and such. After a bunch of digging around the raw project file and much experimenting and such (I hate XCode's documentation, or lack thereof) I found that if you select the target there's an "Upgrade To Native Target" item in the Project menu. Do that and you get a new target with the "A" application icon, and in the Get Info dialog you will find the Properties tab that the Carbon Application target has but the Legacy Application target lacks. There you can enter your icon file name as normal. You'll also need to fill in the name of the executable file, etc.
The frameworks I have listed (other than those specific to my application) in the target, in order (may or may not be important), are Tcl.framework, Tk.framework and Carbon.framework.
The most recent Tcl/Tk build from sources that I did trying to get this to work was via 'make embedded' and 'make install-embedded', I think. But I'm not certain if this mattered in any way - just one of the many permutations of the things tried that didn't, in its self, work (or gave me a different set of problems). It warrants some further testing to figure out just exactly what set of things one needs to do to set up a proper extended/embedded Tcl/Tk application in XCode. Apprently Carbon Application targets are the wrong approach, but maybe someone's had better luck than I with projects that aren't as complex as mine (lots of in-house libraries, generated code of different kinds, several different types of builds of the same things, etc).
MAK (7 Nov 2004) Still having XCode headaches, and having messed with things enough that I've gotten fairly familiar with the basic app bundle layout and Info.plist file format, I gave up on XCode and I'm back to building with plain ol' makefiles and generating the bundle manually (with install). Oh well, it's better in the long run as I'll still have two build systems to maintain instead of a third. Here are a couple of references that might help you do this:
Tk-based applications can look quite good under Aqua. Kevin Walzer gives examples [L7 ].