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: * DPI fix: http://sourceforge.net/tracker/?group_id=12997&atid=312997&func=detail&aid=810026 * Font Rendering fix: http://sourceforge.net/tracker/?group_id=12997&atid=312997&func=detail&aid=638966 * IME: http://sourceforge.net/tracker/index.php?func=detail&aid=622582&group_id=12997&atid=312997 * CoreGraphics update: http://sourceforge.net/tracker/index.php?func=detail&aid=841244&group_id=12997&atid=312997 Approximate list of bugs: * SF tk bug list search for Aqua: http://sourceforge.net/search/?type=artifact&exact=0&q=Aqua&offset=0&group_id=12997&atid=112997 Issues fixed in cvs (but which may not be in a distributed binary release). * Changes to the contents of a label are not redrawn on 'update idletasks' (need a full 'update', I believe). For example Alphatk's status bar shows nothing during startup. This 'label .l ; pack .l ; for {set i 0} {$i < 50} {incr i} { .l configure -text [[string repeat $i 10]] ; update idletasks }' just doesn't do what you want at all! This is fixed in TOT, and I will add the fix to 8.4.6. We just needed to implement XSync. * File filters for tk_getOpenFile which specify a fileType and an extension will only match if the file type and extension match. But the default on MacOS X is for files to have no file type, so these filters will always fail. The solution is that if both and extension & a file type are provided, we will pass files that match the extension, but have no fileType. Outstanding Bugs/Issues as of last change to this page: * No support for -use option to wish, or indeed [Embedded Toplevels] across processes. * Conceptual problem with binds with the "Option" modifier. You can bind to , and you will get the event if that combination is pressed. But the text value is aring, U+00E5 "å", which you will also get in an entry widget, if you don't bind the key (on English and German Macs, other keyboards may assign different codes). You can not bind to or though. * Key events only have keysyms for characters in the ASCII and Latin-1 range, so not e.g. for Hebrew or Greek. Event bindings for those "other" characters are also not possible for this reason. * Input method editors for Chinese etc. don't work. * Occasionally Wish gets confused and bindings don't seem to trigger. Switching to another application and back to Wish gets everything going again. * Builds on 10.2.x won't run on 10.1.x. * No images in menus. ([MAK] - More specifically, it will say "(Image)" for all items in a menu instead of the text if any items in the menu are given an image.) * You can select from a global menu even if there is a grab active. * Torn-off menus have some serious drawing problems: they initially show up as completely black (i.e. a large black rectangle), then as the mouse is moved over the entries, they are filled in, one at a time. * 'focus' and 'focus -force' either don't work or don't work properly. Certainly, for example, if the focus is currently in one toplevel, and you use 'focus -force' to move it to another toplevel, that doesn't raise the toplevel, and generally leaves Tk in a confused state, at times. ''Suggested solution: copy some of the implementation of TkpChangeFocus from tk/win/ to the MacOSX implementation, which looks reasonably generic'' * tk_getChooseColor -title "Foo" ignores the title your provide. * Some encoding issues with file/dir paths in the save/open/directory dialogs * Checkbuttons with long text labels wrap in some circumstances, instead of being truncated. * Setting a button's -padx value to zero (it defaults to 12 (!)) causes a couple characters from the left and right of the button's -text attribute to be chopped off. * Scrollbars issue 'update idletasks' callbacks which have unintended consequences. Best to replace with a manual loop over Tcl_DoOneEvent (for windows events only), or redo the code so it looks more like the windows version which seems cleaner (but has to handle the same event loop issues). * 'tk_getSaveFile -defaultfile /Applications/Alphatk.app/Contents/foo' won't let you hit save (perhaps something to do with the file being inside a bundle?). However, 'tk_getSaveFile -defaultdir /Applications/Alphatk.app/Contents -defaultfile foo' is ok! * 'tk_getSaveFile -defaultfile ... -default dir ...' displays the whole filepath where it should just show the tail, and won't let you hit save. * 'tk_getSaveFile -defaultfile .foo' will not let you hit save. Any '.' file is illegal, it seems. * Using the scroll wheel on a Logitech optical mouse works for scrolling down but not for scrolling up. (the mouse works fine in other OS X applications). * Scrollbar "set" function gives unexpected results. If the slider is set to lenghts greater than 1/2 the total length of the scrollbar, it still displays as less than 1/2 the length of the scrollbar. Issues to be aware of, which may or may not be bugs: * The 'env' array is different for a graphical application versus a command-line one on MacOS X. In particular your $env(PATH) is not the same. This means using 'exec' may fail to find the executable you were expecting. [[see note below]] * Small buttons are tricky, because they are very big. It may be necessary to extend TkAqua to include the small button controls provided by Carbon. 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): * [[file copy]] doesn't copy the resource fork and the MacOS extra file attributes. In the same vein [[file attributes]] and other functions don't know about these. There's a TIP available and a patch to implement this functionality (in Tcl 8.5a0) * Stdin seems, for lack of a better word, funky. On windows and unix we have an app that takes input from stdin and displays it in a dialog (useful for piping output from a spawned process). Typical usage (paraphrased): "exec somethingInteresting | wish dialog.tcl -". works great on windows and unix. Oddly, if I do "wish dialog.tcl -" it works -- I can type data in, type ^D, and what I typed in appears. But if I pipe to wish (which is an alias to wish.app), the read returns an empty string. My code does the moral equivalent of "if {$filename == "-"} {set data [[read stdin]]}". * Current builds on 10.2.x crash if you click in scrollbars anywhere except on the blue bar. * sometimes 'cmd' accelerator is shown in menus when it shouldn't be. * fix to some problems with dead-keys now checked in. * Menu accelerators don't appear in the menus * lots of encoding problems with menus, labels, buttons, checkbuttons etc. * the virtual events <> <> etc are bound to 'ctrl-z/x/c/v' instead of 'Command-z/x/c/v' which is the MacOS X default. * Menu entries with key-bindings are activated even if there are grabs or global grabs active on other widgets * tk::PlaceWindow needs to avoid placing windows under the menubar * wm attributes broken * 'Leave' events seem to be generated even when just circulating inside a widget, when the widget has a balloon-help window associated with it (i.e. there is a floating window around, but nowhere near the mouse). I've done some debugging of this, but haven't yet tracked down whether this is because the wrong window is directly found or because the floater confuses the x,y coords of the event so it then picks the wrong window. Either way the result is that Tk believes the mouse is moving back and forth from '.' to '.win' when it moves (where .win is the thing you are circulating over). * when floating windows are present (tk::unsupported::MacWindowStyle style .foo floating sideTitlebar), mouse events in other windows are screwed up. In particular they are offset in x/y coordinates from where they should be. (So, you click in a text widget, and the cursor moves somewhere else). * events for single modifier keypresses (on their own), e.g. "Control" are not available (the appropriate conversion from Carbon->Tk event doesn't happen). 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: /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''' [http://www.maths.mq.edu.au/~steffen/tcltk/Launcher/] 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 [http://developer.apple.com/qa/qa2001/qa1067.html]. ----- 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''' [http://www.maths.mq.edu.au/~steffen/tcltk/Launcher/] 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 [http://www.apple.com/macosx/x11/] - [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?'' 1. Install the December 2002 Mac OS X Developer Tools software package 1. Go to https://connect.apple.com/ and open a free membership account with the Apple Developer Connection. 1. Log on, click on download software, then click on developer tools. 1. You need to get the gcc updater (currently it is the august gcc 3.3 updater). 1. Start a terminal command line program and you should now find gcc. [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 " 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: * '''Anatomy of a Bundle''' [http://developer.apple.com/documentation/MacOSX/Conceptual/SystemOverview/Bundles/chapter_4_section_3.html] * '''Information Property List Files''' [http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Concepts/ConfigFiles.html] ---- Tk-based applications can look quite good under Aqua. [Kevin Walzer] gives examples [http://sourceforge.net/mailarchive/forum.php?thread_id=5140773&forum_id=3853]. [More MacOS X techniques] ---- [Category Operating System]