The Fugue

I finally got around to building QCad on OS X Leopard. There are two main hurdles: getting Qt3 to build and getting QCad to build.

At first I tried building Qt3 with macports, but building QCad was a royal pain with the X11 version of Qt3 on OS X, for whatever reason. So I tried to install the qt3-mac MacPorts package, but that failed. So I was on my own building Qt3.

This patch will allow Qt3 to build on Leopard, by following the instructions in the INSTALL file. Here’s the diffstat:

 config.tests/mac/mac_version.test |    2 +-
 src/kernel/qcursor_mac.cpp        |    4 ++++
 src/kernel/qt_mac.h               |    2 +-
 src/tools/qglobal.h               |    5 ++++-
 4 files changed, 10 insertions(+), 3 deletions(-)

I put it in /Developer/qt3, and I wrote a script to source on demand rather
than setting QTDIR and friends in my .profile or .bashrc, since I more
often want Qt4 than Qt3. I configure with -static, so applications like QCad
are built with Qt3 statically, which just makes things work better.

QCad needs a patch as well:

Index: qcad-2.0.5.0-1-community.src/mkspecs/defs.pro
===================================================================
--- qcad-2.0.5.0-1-community.src.orig/mkspecs/defs.pro  2008-03-26 08:46:25.000000000 -0600
+++ qcad-2.0.5.0-1-community.src/mkspecs/defs.pro       2008-03-26 08:46:48.000000000 -0600
@@ -1,6 +1,6 @@
 # $Id: defs.pro 606 2004-12-25 03:08:40Z andrew $
-QMAKE_CXXFLAGS_DEBUG += -pedantic
-QMAKE_CXXFLAGS += -pedantic
+#QMAKE_CXXFLAGS_DEBUG += -pedantic
+#QMAKE_CXXFLAGS += -pedantic

 win32 {
   QMAKE_CFLAGS_THREAD -= -mthreads
Index: qcad-2.0.5.0-1-community.src/scripts/build_qcad.sh
===================================================================
--- qcad-2.0.5.0-1-community.src.orig/scripts/build_qcad.sh     2008-03-26 08:46:06.000000000 -0600
+++ qcad-2.0.5.0-1-community.src/scripts/build_qcad.sh  2008-03-26 08:46:49.000000000 -0600
@@ -30,7 +30,7 @@ then
     export MAKE=gmake
     echo "Platform is Solaris"
     platform=solaris
-elif [ "x$OSTYPE" == "xdarwin8.0" ]
+elif [ "x$OSTYPE" == "xdarwin8.0" -o "x$OSTYPE" == "xdarwin9.0" ]
 then
     export MAKE=make
     echo "Platform is Mac OS X"

Then do

cd scripts
./build_qcad.sh notrans

It will complain about not finding qm/*.qm, but that’s a nonfatal error.
QCad.app will be in the qcad directory, ready for your use.

I built this on an Intel MacBook running Leopard. If you think that matches
your setup, you’re free to download my QCad.app and avoid
building both Qt3 and QCad.

For my musical notation needs, I use LilyPond.

LilyPond is to music as LaTeX is to writing. I prefer to edit LilyPond files in Vim and compile them with lilypond at the command line. However, on OS X LilyPond.app is a front end to the compiler. An IDE of sorts. Not a spectacular one, in my opinion, but it does have one thing going for it: when you click on a note in the PDF preview, it takes you that note in your LilyPond source file in the IDE.

On Leopard, LilyPond is severely broken. The IDE will “start”, but there is no menu. Further, if you are on Intel, when you try to run it at the command line, it just keels over and does nothing. It so happens that the workaround to this problem and using LilyPond without the IDE are almost identical solutions, so I’ll describe them as one and the same.

First, and this is the only difference between Leopard brokenness and just wanting to run on the command-line, you want the powerpc version of LilyPond.app, not the Intel version. So go over to the download page and get the ppc version (the one that says it’s for G3, G4, G5 Macs).

lilypond and its friends are in Lilypond.app/Contents/Resources/bin. You could add this to your PATH, but some of the binaries in there are things that I have installed elsewhere (e.g. with MacPorts), and I don’t want them overriding my PATH. Likewise, I want lilypond to be able to find the binaries it expects, and since they’re taking up disk space anyway let’s help it along. So I wrote a script. A LilyPond launcher if you will. I call it ly and put it in my path, and then I call e.g. ly lilypond foo.ly. Here’s the code:

#! /bin/sh
APP=/Applications/LilyPond.app
PATH=$APP/Contents/Resources/bin:$PATH
exec "$@"

Customize APP to point wherever you want to keep LilyPond.app. This will load up the environment that will give lilypond the best chance of success. You can run any of the binaries in that directory with ly, but the most common case is to run lilypond. So I recommend putting this in your .bashrc:

alias lilypond='ly lilypond'

The first time you run the ppc version of LilyPond, or anything else, on an Intel machine, it will seem to take forever while Rosetta fires up. Be patient. Subsequent invocations are quick enough.

growlnotify is a little program that comes with Growl which allows you to submit Growl notifications from the command line or from scripts. Unfortunately, it doesn’t seem to work properly in Leopard—the notification only shows up maybe ⅓ of the time. There’s a hint in the logs, but I have no idea what it means:

2008-02-13 10:09:15 GrowlHelperApp[17821] *** -[NSMachPort handlePortMessage:]: dropping incoming DO message because the connection or ports are invalid

Apparently the devs are pretty clueless about the problem too, as it’s been reported but not yet fixed. The folk(s) over at hasseg.org came up with a workaround, which is all well and good, but I observed a simpler workaround than using the network (which requires configuring growl to allow network connections, if I’m not wrong). This little wrapper script does the trick, at least in my initial tests:

#!/bin/sh
wrappee=/usr/local/bin/growlnotify
exec $wrappee -w "$@" &

Basically we tell it to wait for notification from growl that the message is now off the screen, and then go in the background so we don’t have to actually wait for it. This has the side effect of essentially rendering the -w option useless when using the wrapper, so I’ve decided to wrap it with a different name instead of a transparent wrapper. I call it growl, which is both shorter to type and not nearly as ugly as growlnotify. Enjoy.

One of the more drool-inducing features of Leopard (for geeks, anyway) is Spaces, Apple’s virtual desktop implementation. I’m a big virtual desktop fan, and I’m glad to see it working its way into the mainstream. And all things considered, Spaces is a decent (and beautiful) implementation.

But there are some bugs. I hope that we will see them worked out. Some of the bugs are in Spaces itself, some are probably with 3rd party applications. The most notable, and annoying, problem is buggy application switching. When you cmd-tab to switch applications, you are taken to the space with that application. This is good, but it must have given the Apple developers heartburn because in some ways it flies in the face of the “Apple Way”, which thinks of an application as a whole not as independent windows. That’s why the menu bar is at the top, and it’s behind the design of the dock. But what happens when there’s a Terminal window on this Space, and on that Space? The natural thing should be, switch to the terminal window in this Space. If that’s not what the user wanted, well you can’t be expected to read minds. But when I cmd-tab to Terminal, I am always taken to what Leopard apparently thinks is the master Terminal Space, regardless of whether I have a Terminal window in this space, which Terminal window I last used, etc. Bad news. As a workaround, I just put Terminal on all spaces and thank my lucky stars it has tabs now. This affects most multi-window applications to some degree, but it’s most annoying with Terminal and Adium.

On a related note, I’d expect cmd-` to switch between windows of the same app on different Spaces, but it only switches between windows on the current space.

Some applications, especially Firefox and to a lesser extent Thunderbird, have focus bugs that may be related to spaces. Sometimes when I switch to Firefox (with cmd-tab), the window is not in focus and is not brought to the foreground. The menu bar reflects that I’m in Firefox, and I may have moved spaces to get there, but it’s in the background. I have to switch to it with cmd-` (or, horror of horrors, with the mouse). I imagine this is the sort of thing that Apple and/or Mozilla will hammer out soon. There are other Firefox irritations but they’re for another post—if they haven’t been fixed by then.

So far, nothing too surprising. Virtual desktops is hard to get perfect, and various Linux window managers have been floundering for years or even decades. Overall, I’d say they’re off to a smashing start. I have two other more minor irritations. First, I’d like the current application to stay the current application when I switch spaces with the keyboard, instead of switching to the topmost application in the new space. This is because I often want to choose an application (by cmd-tabbing to it), then navigate to another space where I want to open a new window (e.g. Terminal). This is a design decision, of course, and one that people tend to fall on either side with about 50% probability. The second is keybindings. I’d like to switch spaces with cmd-ctrl-hjkl (Vim keybindings). Maybe we’ll find a way. I’d also like to have more keyboard operations, especially “move me and this window to the {left,right,up,down} space”.