See also the follow-up: How to make X11 work better on Leopard.
In Leopard, Apple switched from XFree86 to X.org for its X11 implementation. This caused a few things to break.
Some of these are legitimate brokenness; some of these are just changes that break people’s expectations. I’ll attempt to list them all here.
In Tiger, when you launch X11, it runs .xinitrc, and .xinitrc runs xterm (unless you comment that line out).
In Leopard, X11.app is just a launcher. All it does is run /usr/bin/login -pf $USER /usr/X11/bin/xterm. In other words, its only purpose is to run xterm (semi-)directly, by itself—it’s not the actual X11 server anymore. When xterm starts, launchd sees it, notices that xterm requires X11, and launches the real X11 server (/usr/X11/X11.app) automatically. The X11 server then runs .xinitrc—but by this time, xterm is already running, so no changes in the .xinitrc can affect it.
This may be just an architectural change: You can’t rely on .xinitrc having been run by the time xterm is running. If not, it’s a bug: .xinitrc is supposed to have completed before any processes that use X11 begin running. I don’t know enough about X11 to know which is the correct behavior.
xterm ignores .Xdefaults when invoked by login
As mentioned above, the X11 launcher does its magic by invoking xterm through login. Unfortunately, when xterm is invoked as a login process (argv[0]
starts with '-'
), it ignores the contents of your .Xdefaults file—no custom fonts, no custom geometry, nothing; just a stock 80×24 black-on-white terminal.
I’ve created a different launcher that doesn’t go through login in order to work around the problem. I call it xterm.app. Since it doesn’t use login, xterm isn’t invoked as a login process, so it uses .Xdefaults, as it should.
Two X11s
X11’s new two-factor design is similar to the design of the mouse-based app launcher Sapiens. Like Sapiens, X11 now consists of a front-end launcher app and a hidden back-end application.
As with Sapiens, this gets confusing if you put the front-end launcher in your Dock, because when you click that tile, two things happen:
- That application exits immediately after you start xterm. Its little white LED comes on for just a fraction of a second.
- When xterm starts, launchd starts the back-end app to support it. The back-end app isn’t an LSUIElement, so it gets its own Dock icon.
The idea is that you should be able to simply launch an app that requires X11, and X11 will start automatically. If you use xterm as your terminal, and don’t use any other X apps (for which purpose you always had to launch X11.app directly), the best replacement (currently) is my app.
Option-click is broken
Laptops don’t have a middle mouse button, which you need if you want to paste into an X11 window. Thus, those of us with laptops have traditionally used X11’s “Emulate three-button mouse” feature, which maps option-click to middle-click and ⌘-click to right-click.
Unfortunately, this is broken in Leopard. Option-click does nothing; in xterm, ⌘-clicking on the scroll bar is acting like middle-clicking should, and ⌘-clicking on the terminal text area itself seems to do nothing but clear it.
It still looks like Tiger
quartz-wm draws X11 title bars with the Panther/Tiger appearance, rather than the new, darker Leopard appearance. It also has Tiger-sized rather than Leopard-sized drop shadows.
Windows don’t stop at the menu bar
You can’t move a regular Aqua window up underneath the menubar. But you can do this with an X11 window. It’s possible to become unable to recover the window this way.
Applications menu doesn’t work with arguments
Added at 15:44 PDT.
Apple’s X11 has always had an Applications menu that serves as a quick launcher for X11 programs. In Tiger, this launcher did the right thing with command-line arguments; either it went through the shell (perhaps using system(3)), or it split up the arguments and passed them separately to exec(3).
Leopard’s Applications menu is broken: It takes the entire command line you defined and passes it as one argument to execvp. It doesn’t know of any program by that suspiciously-long name, so the launch fails and you get an error message in the Console log.
Can’t drag a window to another screen
Paul Thomas mentions this in a comment here, but my friend Alan Boyd has more details:
It seems impossible to move an X11 window on to another monitor. The window itself is able to cross the boundary, but the mouse pointer is not. As a result, the entire window cannot be moved across. I’ve tried doing it in two steps, but once the window is placed on the boundary, it is not allowed to travel any further away from the original monitor.
X11 doesn’t activate like it’s supposed to
More from Alan’s post:
When launching X11 the menu bar is not set up correctly. Instead, the menu bar from the application that was active when X11 was launched is shown, rather than X11’s own menu bar. Clicking on the window that opens seems to rectify this problem.
Basically, X11 doesn’t come to the front when you launch the first process that requires it, like it should.
My xterm.app utility works around this bug, too: it runs its activate application "X11"
script twice in order to make sure it comes to the front.
I will update this post as I find new bugs, and as I file Radar reports for these.