Thursday, April 24, 2008

Settling the OS X focus-follows-mouse debate

I recently switched to using OS X full-time for all my client-side computing. Still using Linux on the backends, of course, at home and at work, but I now use Macs for my client machines.

I'm not a Mac fanboy. I'm sort of a wannabe Mac fanboy, but I'm not familiar enough with the OS yet (either as a user or as a programmer) to really rave about it. I will say this: it was kinda fun turning off that last Windows box for the last time.

My main reason for switching was that I'm getting old and the fonts look nicer. Pretty stupid reason, isn't it? I thought so too. But getting old kinda sneaks up on you. I've gone from preferring six-point font when I was twelve to 20-point font now that I'm 40. So at least for me, my ideal font point size appears to be (age/2).

That sucks.

One day I noticed that I could actually read the screen when I was browsing in the Apple store, and I did some experimentation and found that yes, I can actually read normal-person's fonts on the Mac. And they look kinda nice, too – the antialiasing engine seems to be smarter (and faster) than the ones I've seen on Windows and Linux.

So there ya go. Fonts. And now I have to learn all this new stuff, like what all those weird little symbols mean on the keys, and how to use the Finder, and what a "DMG file" is, and other stuff. But the screen looks soooo nice, so it's worth it. How do they do it? It's not just the fonts. OS X windows look whiter and cleaner than their Windows/Linux cousins running on the same display with similar video hardware. It's a mystery to me, but it's kinda cool.

Almost pain-free migration

I've been using a work-issued MacBook Pro laptop for the past year, and that helped a lot with the transition, since when you're on the road trying to get some work done, you have no choice but to figure out how to do basic OS tasks. So that was a nice, slow, reasonably pain-free way to teach myself the basic skills you need.

I only bring this up because I know a lot of programmers (myself included) who've tried Macs repeatedly and run away scared. If you stick with it a little longer, it's not too bad! Particularly with their latest OS X release (Leopard), it's gotten a lot easier to do basic configuration for people accustomed to Linux.

For starters, it comes with a good X11 implementation, and there is a MacPorts project that ports all your favorite Unix stuff. And they're not lame half-broken ports like the ones you have to live with in Cygwin. For instance, in a Bash shell running inside Emacs you can ssh into a Linux box and not get a bunch of greebly control characters.

And OS X is Unix, based on FreeBSD, so all your normal favorite Unix stuff pretty much works the same, or at least as much as you can expect across different flavors of Unix.

The only real reason I was using Windows at all, to be honest, was for hardware-device compatibility and for multimedia. The Mac has drivers for everything I cared about (my router, my printer, my camera, etc.) and beats Windows hands-down on any sort of multimedia, so it was becoming clear that Windows wasn't buying me much anymore.

I suppose I could do a blow-by-blow guide for how a Unix-and-Windows user can configure their Mac for maximum happiness. If anyone's interested, anyway. Not today, though. The bottom line is that pretty much everything you don't like is configurable... with one ugly exception. And I don't mean "Mary Ann on Gilligan's Island Ugly", either. I mean Ugly ugly.

The Big Focus Issue

Ever since the Dawn of Time (Jan 1, 1970), people have been bitching about the lack of focus-follows-mouse on Mac computers. They started complaining about it fourteen years before the first Mac was even released, that's how bad it was.

Every time they bring it up on Mac forums, the Mac users with non-Unix backgrounds ask "what's that?" And then a bunch of wrong answers start flying around, with a few right answers interspersed but drowned out in the noise.

So let me tell you what it is first, in case you're not from a Unix background. Focus-follows-mouse means that when you move the mouse cursor, the window under the cursor gets the keyboard focus. But saying that confuses Mac people who all assume that "focused" is synonymous with "foreground", because that's the way it works on the Mac.

The confusion stems from the fact that focus-follows-mouse comes in not one, but two, yes that's right, two yummy flavors.

Flavor #1: autofocus — in this flavor, reminiscent perhaps of a sweet juicy mandarin orange, the window under the mouse gets the keyboard focus but does not come to the front. This allows you to interact with a partially-obscured window. It's especially useful when you have a terminal or shell window open, and it's running a background process that you want to observe... you guessed it, in the background! You leave a little bit of the bottom and/or side of the window uncovered so you can keep an eye on the output.

Real-life use case: let's say you're a programmer who writes in C++. You will, of course, spend most of your working day playing Solitaire and reading reddit, because C++ is too goddamned stupid to do anything but gigantic, slow batch compiles of the entire dependency universe. So you have at least four windows open at any given time: your editor, your compile shell, your browser, and your Solitaire game. You've spent a lot of time adjusting your window configuration to be "just right", and unless you have a 30-inch screen (for instance, because you work for Google), your windows overlap.

Watching your compile status is like checking your rear-view mirror; you do it every 7 seconds or so, even though you know the compiler will take a minimum of 15 minutes. It's like a slow-motion train wreck that you just can't tear your eyes from, even while playing Solitaire and reading reddit. And every once in a while you'll need to enter a command (e.g. "make", after you've fixed the umpteenth compiler warning about doing a perfectly valid type conversion). The last thing you want is to have to click the window to bring it to the front just so you can type "make", because then you'll need to go futz around with your window configuration again to get the window to go to back to whatever Z-location it used to be in the window stack.

I know it doesn't sound like a big effort, but programmers are really, really lazy, and they like to minimize motion. They'd use feeder tubes if the Health Department would let them.

So in the autofocus flavor, it's important that the window that gets the focus does not automatically come to the front.

Flavor #2: autoraise — in this pungent flavor, somewhat evocative of a slightly overripe Durian fruit left in the tropical sun for about nine hours, moving the mouse into a new window automatically brings that window to the front. In the especially horrible default configuration, it comes to the front instantly, so the act of moving your mouse across the screen makes it look like that old "rectangles" screen saver, and your window configuration is utterly obliterated in under a second.

Many programmers feel that autofocus is delicate butterfly and autoraise is a big, stinky buffalo. That's just how they feel about it. No accounting for taste. I, for one, think of autoraise as a big, stinky, deceased buffalo carcass that someone thoughtfully dragged into my living room while I was on vacation, probably towards the beginning of the vacation, and then they turned up my thermostat to 110°F, closed the windows and tossed a Durian fruit at the wall for good measure.

But maybe it's just me.

So one of the most annoying aspects of the whole "how do I get focus-follows-mouse behavior on my Mac" debate is that everyone assumes you mean autoraise. There are a number of packages out there, most of them commercial, that offer autoraise as a feature, and Mac users point you to these products and then get all smugly about how they've solved your problem and how Macs still rule the universe, when in fact the problem is still festering away.

It's no wonder people still use Linux as their UI. That one feature alone keeps hordes of programmers from switching. (And yes, you can get the behavior on Windows using their TweakUI power tools, so some programmers use Windows as a Linux shell with a decent media player.)

Super-Stevey to the rescue (well, almost)

Given that I switched quite recently to the Mac, I'm still reeling from the lack of focus-follows-mouse behavior. To help you put yourself in my shoes, imagine that your latest operating system upgrade (whatever OS you happen to be running) includes a new mandatory feature wherein each time you click on a window to focus it, a loud alarm goes off ("BLONK! BLONK! BLONK! ...") and you have to open the System menu and select "silence window alarm" to shut it up.

That's what not having autofocus is like to people who've been using it for the past 10 to 30 years (in my case, 20 years). BLONK! BLONK! BLONK! I'm serious. It's that bad. Not exaggerating even a tiny bit.

I'm sure you could eventually get used to this behavior, and even find yourself arguing on newsgroups that you rather like the blonk blonk sound, since it reminds you that you've recently chosen to switch to another application or to another window within the current application, plus it's really not that big a deal because you can just open the System menu and turn it off.

It's amazing how so many people choose to rationalize stuff they're forced to live with. Why not just admit it sucks? Sometimes stuff sucks! C'mon, admit it! Jeez!

But even if you eventually managed to rationalize it, you'd be pretty fugging pissed off the first, oh, ten thousand or so times it happened to you after the upgrade.

So the other day, after the 100th or so BLONK! BLONK! BLONK! alarm when I innocently tried to type into a different window, I found myself quietly contemplating the pros and cons of getting an assault rifle, heading down to the Apple campus, and making my opinions known to all until the SWAT team took me out. And then I thought: "hey, as attractive as that option sounds right now, I have a better idea: why not fix it myself? I make occasional claims to being a programmer, right? How blonking hard can it be? I'll budget one evening for it."

I actually wound up spending 2 evenings on it, since although coming up to speed on the Apple tools and APIs was almost trivial, this particular issue turned out to be thorny in a variety of unexpected ways.

But I did get it working, for some definition of "working", and now I'm in a position to settle the debate for the forseeable future, which I estimate to be about the next five to seven years in this case.

The Definitive Answer

Short version: you can almost get it working, but not quite, on account of an arguable bug in one of the Carbon (that is, Mac C++) APIs. What I got working was a system-wide autofocus mode that unfortunately only re-routes unmodified keys to the window under the cursor. You can fake the Shift modifier by translating the key code manually, but the Control, Command and Alt/Option keys never make it through to background applications. (They do get delivered to the foreground app if your mouse is there, so the bug only happens for background apps.)

So if your use case is limited to, say, typing commands into a command shell, and you don't need to use the control, alt or command keys, then you can have working autofocus! In fact, you can even make it so that only your terminal windows (or any application list of your choice) get the autofocus behavior, and all other applications get the normal must-click-to-focus behavior. So even my "failed" attempt might yet hold some small utility for us ancient Unix hackers. I'll play with it for a while and see.

Long Version: As close as I came in my little 2-day effort, I now believe at this point that it's unlikely that autofocus will ever be available on Macs, sad as that news will be for thousands of would-be Mac users. And not just any users: they're programmers, all potentially capable of learning to write Mac applications and collectively enhancing the value of Apple's platform. So it's kind of a big opportunity cost for Apple. But there are both technical issues and design issues that make it a serious problem to support autofocus on Macs.

It's probably not impossible, but the cost is high enough that when their OS engineers think about tackling it, they'll probably decide it's not worth the effort, since the company seems to fail to appreciate just how big a stumbling block the lack of autofocus-sans-autoraise really is for so many competent Unix programmers out there.

So, Apple OS engineers, I'm not saying you're not smart. I'm just saying you're not smart enough. ;-)

Just kidding, of course, and I'll dispense with the child psychology. Here's why I think they're not going to fix it. The rest of this blog entry consists of boring technical details, so if you're getting antsy, please feel completely free to skip to the very end.

How it works

First, one caveat: I'm not a Mac programmer. I don't even play one on TV. I just downloaded Xcode (their development toolkit) for the first time three days ago. I've never written any Mac programs before this one, not even an AppleScript script, and I only started looking at their APIs a couple days ago. So I might be wrong about some or all of this.

The first problem you encounter is that there's no public Mac API for getting any sort of usable handle to a running application so you can interact with it programmatically. This is apparently for security reasons. I won't harp on this decision, although it does seem odd to deny sophisticated (read: sudo-enabled) users the choice of loading privileged apps into their system. Any application can run amok with your filesystem, personal data and network connection, so it seems odd that you'd arbitrarily choose not to let them also run amok with your other running apps.

In any case, there's a loophole. Apple, out of sheer generosity, goodwill, and the kindness of their heart o' hearts, and also partly because United States Federal Law requires it, but mostly out of sheer generosity, goodwill and the kindness of their hearts, has provided a set of "Accessibility APIs" that give you a certain federally mandated level of remote control over running applications in the system.

OS X actually has two more or less discrete sets of APIs: one for C/C++ (Carbon), and one for Objective-C (Cocoa). Cocoa incidentally also happens to be the API you use for Python and Ruby scripting on the Mac; I took a detour for a few hours and learned the basics of RubyCocoa, and was quite pleased at how well it worked.

One of the reasons I took the RubyCocoa detour was that the subset of the Accessibility APIs I needed for implementing autofocus is fairly cumbersome to explore using C++ and Xcode. I made an executive decision to spend (and potentially waste) some time seeing if I could make faster progress using one of the scripting APIs, because I was encountering bugs and/or unexpected behavior that called for some exploratory programming.

Carbon offers an abstraction called an AXUIElementRef, which is a proxy object representing a UI element (e.g. an application, a window, or widget) in any running app on the system. This subsystem is designed and implemented entirely using the Properties Pattern, which, as it happens, I'll be blogging about at length in the very near future. Normally this pattern is quite flexible, and I can fully understand their reasons for using it here: it gave them legal compliance with an absolute minimum of effort.

But the Properties pattern is healthiest in a dynamic environment that lets you poke around reflectively to get the names of properties, fetch their values, traverse parent links, and so on. Carbon provides APIs for manipulating all these UI-element properties with C++, but it really is cumbersome: lots of casting, lots of wrappers, lots of recompilation every time you want to try just one more thing. Call me spoiled, but I only budgeted a day for this feature!

So I learned a bit of RubyCocoa, and it appears – as far as I can tell – that the relevant Accessibility APIs are only available through Carbon, and not through Cocoa, which means if you want to use them, you can't use Objective-C, Ruby or Python. Or at least I couldn't find a way. If I'm wrong, someone please correct me, since I'd really like an experimentation platform that handles Carbon APIs that have no Cocoa equivalents.

Really Grubby Details

I told you it'd be boring! What are you still doing here?

OK, whatever. You're a glutton for punishment, I tell ya.

There are three basic components to the focus-follows-mouse solution:
  1. Create an "event tap" to filter all system keypresses.
  2. Find the frontmost window under the mouse
  3. Redirect the keypresses to that window.
That's all there is to it. This is the solution I envisioned before I'd even downloaded Xcode, and unsurprisingly, it appears to be the only reasonable way to accomplish the task in OS X. I mean, how else would you do it?

The event-tap API is straightforward, with just one teeny, minor exception almost not worth mentioning, which is that it doesn't work. It compiles, runs, and fails silently. This took me several hours to figure out. It turns out that event taps are considered to be part of the Accessibility APIs, and for security reasons, your process either has to be running as root, or you have to enable "assistive technologies" in the Universal Access section of System Preferences. I stumbled across this in some random newsgroup after a LOT of searching. In retrospect it was kinda there in the API documentation, but they didn't make it super clear.

Whew! There went several hours down the drain, but now I had a C program that fired up and listened for keypresses, printing them to stdout. The event-tap API gives you the option of swallowing the keypresses (or changing the event, or even returning a new event to replace the old one), so it's plenty flexible enough for our needs.

Next, I needed to find the window under the cursor, which first meant finding the global cursor position. This also turned out to be surprisingly non-obvious. The best solution I found, from someone's blog, was to create a NULL event and then get its mouse coordinates. So intuitive! Just like Mom used to do it!


Once you have your mouse coordinates, you use a "hit test" to find the window at that screen position. It's one of two Carbon-only APIs you need: you create a proxy for the system-wide UI object with AXUIElementCreateSystemWide, and pass it to the global hit-test function AXUIElementCopyElementAtPosition to get the UI element under the mouse.

Then it gets a little ugly, though not terribly so. These AXUIElementRef objects have all their information in property lists. This would be trivial to navigate in RubyCocoa, but the AXUI API set doesn't seem to exist in Cocoa — specifically the parts that deal with "any running application" rather than "your application".

So you grub around in the object and its parent chain, clunkily printing stuff in C++ and releasing reference-counts, until you find an ancestor with a "role" attribute of "application". That's the element you need for delivering keyboard events.

We can deliver the keyboard event to the unfocused window, through this poorly-documented API call:
AXError AXUIElementPostKeyboardEvent(AXUIElementRef application,
CGCharCode keyChar,
CGKeyCode virtualKey,
Boolean keyDown);

All good so far. Excluding the time spent figuring out the access-control problem with event taps, and the time spent playing with RubyCocoa, I'm only about five hours into the whole endeavor.

Oh yeah, and the time spent dicking with Xcode trying to figure out how to add a library build target to the executable. I've done it two or three times now and still can't remember how I did it.

The AXUIElementCopyElementAtPosition function points you to its non-Accessible cousin CGPostKeyboardEvent, which is also more or less undocumented. Can you tell they really don't want you to use this stuff? This cousin function has a teeny bit of explanation in its header file CGRemoteOperation.h, which Xcode provides no easy way of locating via search. You can look for it in Spotlight, hoping you'll get lucky and it won't hang like it did for me just now. Or you can do what I did and just use Google Desktop search to pop to it instantly.

The explanation in the header file says:
* Synthesize keyboard events. Based on the values entered,
* the appropriate key down, key up, and flags changed events are generated.
* If keyChar is NUL (0), an appropriate value will be guessed at, based on the
* default keymapping.
* All keystrokes needed to generate a character must be entered, including
* SHIFT, CONTROL, OPTION, and COMMAND keys. For example, to produce a 'Z',
* the SHIFT key must be down, the 'z' key must go down, and then the SHIFT
* and 'z' key must be released:
* CGPostKeyboardEvent( (CGCharCode)0, (CGKeyCode)56, true ); // shift down
* CGPostKeyboardEvent( (CGCharCode)'Z', (CGKeyCode)6, true ); // 'z' down
* CGPostKeyboardEvent( (CGCharCode)'Z', (CGKeyCode)6, false ); // 'z' up
* CGPostKeyboardEvent( (CGCharCode)0, (CGKeyCode)56, false ); // 'shift up

That's it. That's what they give you. Open questions about the explanation include (a) why are they passing capital-'Z' if they already reported that the shift key was down, (b) if there's a guesser when you pass NULL, why do you need to pass 'Z', (c) how do you get the char code for a given key code, and is it the same on all keyboards, and (d) why didn't they include a "THE FIRST PARAGRAH IS A LIE" disclaimer around the first paragraph?

Open questions be damned. We fearlessly press on, and just pass "whatever" and see what happens. Specifically, I always pass NULL for the char code, and pass the key code I got from the event tap callback as-is.

And it worked! Sort of! I start my little app (which has no UI), move the mouse into a window from a non-foreground application, and I can type into it!

Except I can only type unmodified keys. It's completely ignoring my keyboard event posts for Shift, Control, Alt and Command. That's the lie part. They said they'd generate flags changed events. They lied.

After some more painful C++ experimentation, I find that the call does NOT ignore modifier keys when posting to (a) the focused application or (b) the system-wide application, which just posts to the focused app. The call only drops modifier keys on the floor for non-focused apps.

There's a big ol' thread about this exact problem from six years ago on the Apple accessibility-dev mailing list. Six years! I read every last word of the thread.

The first takeaway is that Apple OS engineers don't want you to do stuff that they don't want you to do, and they specifically define "stuff they don't want you to do" as "stuff they don't think you want to do." This is actually endemic to Apple forums in general. Whenever someone says "I want focus follows mouse behavior!", some people inevitably reply that "you really don't want to do this". It's that whole "we designed it the right way for everyone" mentality that turns off so many would-be Mac users.

For what it's worth, the Apple engineers really were trying to be helpful in this guy's situation, and I know how hard it can be to respond to a mailing list in the capacity of "developer representing the company". But it took them a long time to understand his needs, because (and I'm speculating here) they implemented the Accessibility APIs only because their Mom told them to, and they don't truly appreciate at a deep level what it means to have a disability, and how important it is for many people to be able to choose a different UI paradigm.

And yes, I am taking the arguably un-PC position that having your fingers hardwired to focus-follows-mouse from 20 years of use can be viewed as a minor disability of sorts. I'll be the first to admit that it's not the kind of "real" disability the government probably had in mind when they mandated the Accessibility APIs.

But I did switch to the Mac because my eyes are slowly beginning to fail. Ironic that I should be forced to trade one disability for another.

The underlying issue

OK, let's assume for the moment that Apple really does have our best interests at heart, and that they can get over the painful notion that their usability test findings may not actually apply to 100% of all users 100% of the time.

Even if they wanted to help fix it — and in this case, all they'd need to do is NOT drop the modifier keys on the floor when you call AXUIElementPostKeyboardEvent — there are some deep-rooted architectural issues at play here, and I finally "got it" while reading that thread.

The problem is that Macs, always and forever, have put the menu bar of the focused application at the top of the screen. The menu bars of unfocused applications are hidden and are not in any way user-interactible.

As you might expect, this UI assumption has been baked into the Mac APIs from the very beginning. Programmers will take advantage of any axiom they can in order to get things working, so over time this has turned from a UI design assumption into an architectural "feature".

In particular, when an app is in the background, its menu structure may not be intact, and the app may be in a state that assumes it will not be receiving any keyboard input. One concrete example mentioned in the thread was that when an app is in the background, the child menu items do not have parent links (although the parents still have pointers to the children.)

This has serious ramifications for focus-follows-mouse. There are certain built-in hotkeys that can activate menu entries, and apps are also free to define their own. If you try to activate a menu in a background application, it could in theory wind up crashing the app, if the app is assuming an intact menu structure and is traversing bottom-up rather than top-down.

You could attempt a knee-jerk solution by allowing Control and Alt through, but deny the Command modifier, since that's the most common menu-activation modifier (I think). But there's another class of applications (Emacs included) that dynamically generates at least part of its menu structure based on the data content. For instance, the Emacs Imenu package generates a list of jump targets from a source-code buffer. Even typing a new function definition could still trigger a rebuild of the IMenu, which (for all anyone knows) could crash Emacs.

You could of course ask app developers to fix this on an application-by-application basis, but there are generations of legacy apps that can never be fixed. The only way to guarantee that pressing a key could never crash an application would be to fix the OS X user-interface architecture to normalize application behavior for foreground and background operation. This could be hard. It could expose its own set of difficult or even intractable problems for legacy apps. Or maybe it's really easy. I don't know, since I can't see their code. But I suspect it's not easy.

And Apple has no real motivation to fix it, because their UI was designed for "everyone". People who would use focus-follows-mouse are presumably a tiny minority, so even if they're mostly programmers the cost/benefit likely isn't there.

It is, of course, completely fixable if Apple really wanted to fix it. I've heard many war stories over the years from Microsoft folks who've had to put compatibility hacks into OS releases, some quite extensive, in order to support popular applications that relied on undocumented OS behavior that suddenly broke. Imagine those poor guys that had to implement perfect DOS/Windows emulation on NT, for example. I suspect that by comparison, fixing focus-follows-mouse would be relatively straightforward.

But I predict it won't happen in the next 5 to 7 years, unless the government suddenly decides that this API is required for properly assistive technologies.

It's interesting that you can get so close using the existing APIs: I have true focus-follows-mouse behavior implemented for non-modified keys. Sure, the window doesn't actually focus, so some applications don't even show a cursor. But if you're willing to live with occasional glitches, the feature works great.

In any event, what's weirdest about all this is that the API lets you send non-modifier keys to the background app, because as I pointed out, it's still possible for vanilla keys to crash applications! If the state of the app is materially different when it's unfocused, and the app isn't expecting keyboard input when unfocused, then it could crash. Dropping the modifier keys on the floor may reduce the probability of Badness, but it certainly doesn't eliminate the possibility.

Was it an accident that they let any keys through at all? That would surprise me greatly, since the OS engineers seem determined to close undocumented behavior loopholes. But if they had a reason (perhaps a legal reason) to permit unmodified keys through, what was it about the reason that lets them drop the modifier keys?

I wish I knew.

Open letter to the Apple Wish Fairy

If I could wave a magic wand, I'd ask for them to fix the API to pass the modifier keys along to the app, and just put a note in the docs that Bad Things could happen, so Buyer Beware.

They already do this for those exact APIs anyway. CGPostKeyboardEvent's documentation says: "This function is not recommended for general use because of undocumented special cases and undesirable side effects." And this is for the API that only talks to the focused foreground app! The AXUI version is obviously double-buyer-beware, and apps can't even use it without prompting for the superuser password, unless the user has purposely enabled assistive technologies.

There would be bugs, yes. Some applications would have to push out new releases to properly support focus-follows-mouse, and some legacy apps would never be fixed. But you could disable the behavior on an app-by-app basis, or just take a "Doctor, it hurts when I do this" approach.

Unfortunately I don't have a magic wand; all I have is my distinctly nonmagical blog, which I'm using to soothe myself via copious whining.


This whole thing has been an interesting lesson in how the government can actually force companies to open up their locked-down systems. The whole "you'll have it our way, and like it" mentality is crumbling with these assistive technologies. I hope the feds mandate opening things up even further, since we're only partway there so far.

In the interim, I'm sure I'll eventually get used to life without autofocus. BLONK! My 30-inch screen helps, as does Spaces, since it's easier to give windows their own non-overlapping real estate.

I might even give autoraise another try. Some developers have implemented it in a horrible way, by generating a mouse click when you move the mouse into a window, which often results in activating UI objects unintentionally just by moving the mouse. Ouch. But there might be some commercial implementations that do it "right", or I can just hack my autofocus app to do it that way. Combined with an autoraise delay and minimizing my overlapping windows, it might just work. We'll see.

And everything else so far about the Mac has seemed pretty nice, or when it's been not nice, at least it's been fixable with a little configuration effort. I liked the OS X APIs on the whole, and the RubyCocoa thing is pretty sweet. I might even wind up writing some native clients — something I thought I'd never do again, given how awful my Windows native-client experiences have been over the years.

So I'll keep using my Macs. They're all just plumbing for Emacs, anyway. And now my plumbing has nicer fonts.

If you skipped straight to the end... didn't miss much. See you next time!


Blogger Brad Fults said...

My question is: what the hell is your hand doing on your mouse when you want to type something? CMD+Tab is your best and only friend.

(Yes, I read the whole thing.)

8:32 PM, April 24, 2008  
Blogger Peter Michaux said...

I was just going to write what Brad wrote. Command-Tab, Command-Shift-Tab, Command-`, and Command-~ are the ways around.

8:35 PM, April 24, 2008  
Blogger David Avraamides said...

It may not work for all apps, but since you are mostly interested in shells, supports this:

defaults write FocusFollowsMouse -string YES

8:39 PM, April 24, 2008  
Blogger trace.log said...

CMD+Tab is nice and all, but it's much slower to switch to a window you can (partially) see compared with focus-follow-mouse. This is especially true when you are working on a laptop where the touch pad is right under your thumb and your window is furthur back in the switch list. At least when I CMD+Tab, I tend to overshoot.

8:56 PM, April 24, 2008  
Blogger jrockway said...

There is always Mac::Carbon for interacting with Carbon. I'm not really a Mac user, though, so I've never tried it:

9:09 PM, April 24, 2008  
Blogger blasdelf said...

Apple does actually provide a way to diddle with every GUI application running as your user. They're called InputManagers, and they were intended for supporting international text input methods. Apple used them to implement CJK input along with a few others.

LaunchServices attempts to load them into the process space of everything you launch. People write 'plugins' for specific applications by having `if app != "Safari"; exit(0);` be part of their init process.

You could use an Input Manager to basically cause the only the Menu Bar to be raised (it's a window!) on a focus event.

There is a real reason the Apple people did not think this would be a good idea to implement: It would completely wreck keyboard shortcuts unless you were a vigilant mouser, especially for applications with palettes like Photoshop.

Does your focus-follows-mouse app cause the window to be visually focused too? (in 10.5 the window decorators get dark grey, the buttons and scrollbars gain color, and the window shadow gets HUEG)

Please post sourcecode!

9:14 PM, April 24, 2008  
Anonymous Anonymous said...

I got as far as to when the line-spacing changed, then I stopped reading 'cause it looked too cramped.

9:21 PM, April 24, 2008  
Blogger Alexander Strange said...

I think InputManagers are only loaded for Cocoa apps.

The complete way to do runtime patching is APE ( which will cause a lot of people to get mad at you for no actual reason. And you might have to learn how the Objective-C ABI works.

(But you should do that anyway if you're going to be a language expert; the data structure stuff in Cocoa is brilliant)

9:26 PM, April 24, 2008  
Blogger Peter Hosey said...

I know you're not big on auto-raise, but there's an app called MondoMouse that provides it for you. It has a one-second delay, and you can restrict it to only switch when modifier keys are pressed (default: ⇧⌃).

It's shareware; the trial period is 30 days, after which it costs $15 USD.

9:49 PM, April 24, 2008  
Blogger Ryan said...

So it's OS X not OS/X.

Also the single menubar has a couple of advantages you kind of gloss over. One of the problems with a 30 px tall window bar is it can be hard to mouse on it. There is a principle named for this, but I forget what it is now.

Whereas the mac menu-bar is infinity pixels tall. Easy to hit.

Another thing is Apple's UI is application-oriented, not window oriented. I highly recommend the use of Cmd-H to hide applications when you are 'done' with them. I never ever minimize windows.

I'd also give Expose a shot. Come by my office if you want a demo sometime.

9:58 PM, April 24, 2008  
Blogger Jeff said...

"So I'll keep using my Macs. They're all just plumbing for Emacs, anyway. And now my plumbing has nicer fonts."

Then just use friggin' X11 and set auto-focus and be done with it.

you *can* use Xcode from a commandline

10:05 PM, April 24, 2008  
Blogger bawb said...

Also the single menubar has a couple of advantages you kind of gloss over. One of the problems with a 30 px tall window bar is it can be hard to mouse on it. There is a principle named for this, but I forget what it is now.

Fitts's law

10:25 PM, April 24, 2008  
Blogger Darren said...

iTerm is a wonderful replacement for Terminal. There are two feature of it that you might like. It does focus-follow-mouse (correctly), and it looks nicer than Terminal (I swear the fonts are rendered better, but they are likely rendered identically)...

Emacs should run great in it too :).

10:25 PM, April 24, 2008  
Blogger Michael Head said...

I find it funny that the first two comments were precisely of the sort mentioned in the post about what happens when this topic is brought up in forums (even with the disclaimer).

With respect to the technical problems, is there some way to trigger the menu to activate without the window raising? Perhaps by patching into whatever process is acting as OS X's effective window manager?

10:31 PM, April 24, 2008  
Blogger blasdelf said...

iTerm pretty much only exists because used to not have tabs, and lots of people aren't cut out to be GNU screen users!

iTerm also used to be horrifically slow at rendering text, at least compared to It might have been fixed at some point recently. One of my coworkers was using it because "it has alpha transparency" — no, it just has it on by default! is by far my favorite GUI terminal emulator (top overall is screen), on other platforms I use xfce4-terminal.

10:32 PM, April 24, 2008  
Blogger Denton Gentry said...

> I got as far as to when the
> line-spacing changed,
> then I stopped reading
> 'cause it looked too cramped

The Minima template puts its "line-height: 1.6em;" style on the <p> tag in the posts. However the presence of another block level tag will end a <p> block, and its style will not be applied to subsequent text. In Steve's current posting the culprit is the ordered list tag, after which the lines revert to 1.0 spacing.

I modified the Minima template slightly for my own use ( to add line-height to the enclosing <div> in the posts section like so.

.post p {
  margin:0 0 .75em;
/* DGentry added; enclosed block tags screw up the paragraph formatting */
.post div {

There may be better CSS techniques to resolve the problem, but this one works for me.

Unfortunately it turns out that nicely spaced lines do not significantly improve the mindless drivel I generally post, and thus the effort was for naught.

10:34 PM, April 24, 2008  
Blogger Dethe Elza said...

"The first problem you encounter is that there's no public Mac API for getting any sort of usable handle to a running application so you can interact with it programmatically."

Not sure what qualifies as a "useful handle" but NSWorkspace should get you a good start. From Python:

from AppKit import NSWorkspace
running_apps = NSWorkspace.defaultWorkspace().launchedApplications()

That will a tuple of dictionaries with info on all running applications. You can communicate with them via AppleScript Events, signals, and many other ways.

The Mac APIs took me a lot more than 3 days to grok, but the AppKiDo (free, open-source) tool goes a long way towards making them easier to learn.


10:35 PM, April 24, 2008  
Blogger Cable Ray Wire said...

A few notes:
APE doesn't work on leopard.
There were apparently some major back-end code changes from 10.4 to 10.5.

AppleScript also can access the accessibility API.

Anyone interested in system-architecture modification and programming may want to check out the Mac OS X Internals book. It's pretty much the definitive book on that topic.

10:38 PM, April 24, 2008  
Blogger Dethe Elza said...

Oh, and about those "other ways" to communicate with running applications that I casually glossed over in my previous comment, the best reference I know of to that is by your fellow Googler, Amit Singh: Mac OS X Internals, A Systems Approach.

This book weighs about 3000 kilograms and the Israeli Special Forces teach a form of martial arts using it, but it is the best place I know of to find details of the inner workings of OS X. Aaron Hillegass's books are good sources too.

10:49 PM, April 24, 2008  
Blogger Steve Yegge said...

I'm truly astonished at how many completely uninformed, knee-jerk replies I've received already. What the hell?

brad fults: laptop trackpad is accessible from home row without so much as turning my wrist. more to the point, switching with the keyboard raises the target window!

david avraamides: the article clearly says X11 already supports focus-follows-mouse. Thanks for sharing!

peter hosey: do you honestly think I don't know about MondoMouse? I researched the ever-loving crap out of this topic. And do you think I'd pay fifteen bucks for something I can make my own application do for me?

Ryan: are you honestly trying to tell me that I should "prefer" the menu bar at the top? Did you even read the f-ing article?

jeff: did you read the article or just the last paragraph? I state explicitly that X11 ports are unsatisfying and that I won't use them.

dethe elza: it doesn't work, for christ's sake! do you honestly think I didn't look at that API? there's a whole frigging thread on the Apple forums about how that EXACT dictionary doesn't help at all for this problem.

cable ray wire: AppleScript can NOT access the Carbon-only APIs I listed here. Do you really think I didn't try that?

You people are missing some really fundamental points here. One of the most important ideas in this article is that you should never assume that someone likes it your way. So don't tell me what I want.

And as for the API suggestions: I already looked at all your B.S. little APIs, and they don't work. The Carbon-only AXUI APIs are the _only_ viable solution to this problem, and they are bugged.

Folks: if you don't use focus-follows-mouse, don't make arbitrary claims about how "your way" is faster or better. I ridiculed those people in this blog. Don't be one of them!

I'm tempted to shut off comments so I don't have to hear any more of this drivel. This is the worst blog commentary I've ever had, and it doesn't speak well of the Mac community.

I'm heartened by one intelligent email I've received on the subject so far, so I'll turn comments back on for another day or so and see what turns up.

As for the other comments so far:

- blasdelf, thanks for the tip. I'll look into it, though I'm unhopeful.

- jrockway: I've kinda sworn off Perl, but thanks all the same.

- bob and denton: thanks - I'll try to apply the css patch to my template, although I loathe messing with it. but I hate the decreased spacing as well.

1:51 AM, April 25, 2008  
Blogger gw said...


Just thinking out loud - and i doubt it - but is it possible to activate the menu of an application without raising window focus?

1:54 AM, April 25, 2008  
Blogger Steve Yegge said...

p.s. -- Denton, you're a genius. Thanks for the fix!

1:56 AM, April 25, 2008  
Blogger Steve Yegge said...

gw - highly unlikely. I'm only looking for a solution that lets me do things in windows that don't require menu interaction. For instance, GMail and Emacs both manage their own hotkeys and don't need an active menu in order to edit and navigate with the keyboard.

1:58 AM, April 25, 2008  
Blogger Al. said...

After switching from Linux and various other types of UNIX to a Mac a few years back this drove me nuts. Suffice to say I've got used to it, the "Boink! Boink!" noise no longer bothers me that much, I only want to throw the laptop out of the window one or two times a day now. This sudo'ed nudge to the defaults,

defaults write FocusFollowsMouse -string YES

which got mentioned further up the comment stack helped with the initial transition and carried me over the weeping and tearing of hair stage at least.

Of course its this way for a reason, the OSX desktop is application rather than window focused. Its a real design discussion rather than a lack of features.

No, that didn't help me come to terms with it either...

2:14 AM, April 25, 2008  
Blogger Jeremiah said...

All I know is that auto-focus is the biggest thing I miss when I leave my linux box. That and highlight+middle-click for copy and paste.

These two things enable me to do a lot of things much faster than I would be able to do without them, and at this point in time I can't imagine moving to a machine that doesn't support them.

2:26 AM, April 25, 2008  
Anonymous Anonymous said...

This was my main problem also when switching to Mac a few years ago (after Linux/Windows with TweakUI). I still hate how focusing is done on the Mac but I am already used to it.

Thanks for brining this issue into focus!

How I wish it could be fixed in a proper way! I will desperately wait for a fix...

2:33 AM, April 25, 2008  
Anonymous Anonymous said...

Focus follow mouse is the only UI thing I miss from my days with Solaris, etc. I have almost got used to it through using things like Expose. I do like you how can use the command key to use the mouse to interact with background windows without bringing the window forward - it seems odd to me that is offered, but keyboard entry isn't.

2:35 AM, April 25, 2008  
Blogger Stu said...

Annoying to hear this isn't available on the mac... funny, I've been thinking an sloppy focus hall of shame is needed; for apps that misbehave... there are still a few in linux, but mostly I was thinking windows apps.
Eclipse in windows is a nightmare, popping up gui elements when you mouse over it, there are many other windows apps that misbehave with it, but I still put up with it - I can imagine using the mac with it would be similar... heres hoping apple fix the accessability library one day :)

2:40 AM, April 25, 2008  
Blogger Toby said...

If you decide to make the code available (even without modifier key passthrough) I will be eternally grateful.

I've been Mac-only for the past couple of years, after about 10 years of focus-follows-mouse on Unix, and this has been my biggest gripe. I can and do live without it, but I still miss it enormously.

(My second biggest gripe is, as you emphasize, the fact that when you complain about this, everyone thinks you mean focus-follows-mouse-and-autoraise, which is HORRIBLE.)

2:43 AM, April 25, 2008  
Blogger Nikolai said...


I guess you aren't praising follow-focus as the killer feature and the ultimate solution to many problems, even though it could certainly sound so. I just want to put my two cents in: I find follow-focus extremely annoying, because I'm not working on a notebook and I consider the hand moving distance to the mouse significant. I'm a keyboard junkie and I don't really follow the position of my mouse in all the detail and it happened every time that I switched to another window with alt-tab but haven't got it focused because the mouse has been in the way. If I had my mouse as a primary "interaction device" follow-focus would have mattered, otherwise it stinks. When I get a keyboard with a trackpoint or maybe a Slider from Simtrix, maybe I'll change my opinion.

2:49 AM, April 25, 2008  
Blogger Chris H said...

Steve, regarding the last two people you complained about (cable ray wire & dethe elza): If you don't want people to make API suggestions THEN DON'T ASK FOR THEM. (I don't think you mentioned their suggestions in your original post, please ignore my post if you did.)

Ok, so their suggestions happened to not work, but sadly not everyone is as amazingly intelligent & all-knowing as you are.

I hope you were just having a bad day when you wrote your reply.

2:50 AM, April 25, 2008  
Blogger Steve Yegge said...

i5m - interesting point. A related observation is that you can scroll-wheel scroll background applications. So perhaps the whole issue of background apps being poorly prepared for user interaction is a myth?

It occurred to me after writing the article that if Apple really wanted to fix this in a first-class fashion, they could do it with two new options. The first, disabled by default, would be "Mouse motion focuses app under the mouse", as if you'd clicked in the window. The second option would be: "Auto-raise apps focused through mouse motion", enabled by default. If you turned it off, then the newly-focused app's windows wouldn't automatically come to the foreground, but everything else would work as it does now.

This would be a far better solution than the API hack I've suggested. Let's hope that wish-fairy is listening.

2:51 AM, April 25, 2008  
Blogger Toby said...

Actually, I'd send a different letter to the Apple Wish Fairy; I'd ask that it be possible to decouple "making an application active" from "bringing its window to the front"

That is, you could make an application active - change the menu bar at the top of the screen, make it receive all keypresses, etc - without changing the z ordering of any windows.

In fact, I reckon that's probably much more achievable, since it happens (presumably buggily) on a fairly regular basis if you switch autoswoosh off in Spaces.

2:57 AM, April 25, 2008  
Blogger Steve Yegge said...

Chris H: yes, I was having a bad day.

That said, it seems lame to suggest an API call without bothering to go research it for a few minutes first. Why put the burden on me? It's better for everyone if they research it first. That way if they're right, they get full credit, and if they're wrong, nobody needs to read the suggestion.

This is morally equivalent to asking people to search for duplicate bugs before reporting their own bug. It's basic netiquette. I think it's perfectly fair for me to expect a modicum of due diligence from commenters who claim some proficiency with the Mac APIs.

2:57 AM, April 25, 2008  
Blogger Toby said...

Sorry, last comment cross-posted with Steve's, making the same suggestion.

2:59 AM, April 25, 2008  
Blogger Eritreo Cazzulati said...

Yet another case of "switcher wants to do things the same exact way he did before". I can assure you that it's way more profitable to learn the new OS conventions instead of working around them to mimic the old OS.
Putting in a new preference doesn't solve the problem: they won't be doing it because... there is no problem. This is a precise design choice, and a fundamental part of OS X UI design (which, in case you didn't notice, it's quite important to the OS itself).
My advice: stop trying to make OS X behave like another OS (and begin pressing F9, BTW)

3:01 AM, April 25, 2008  
Blogger Henrik Nyh said...

Somewhat related: you can control background Cocoa apps (and at least the native title bar of non-Cocoa apps like Firefox) with the mouse, without bringing them to the foreground, if you hold the Commmand key.

That's mouse only, no keyboard input, so it probably doesn't scratch your itch, but perhaps it's of interest.

3:09 AM, April 25, 2008  
Blogger Weeble said...

Inspired by the note that Windows supports focus-follows-mouse using TweakUI, I decided to give it a go. I gave up after five minutes: it seems that tool windows (at least in Visual Studio 2005, on XP) are automatically raised to the top of the Z-order as soon as the application gains focus. Oh well, maybe it is too much trouble to try to "go against the flow".

3:10 AM, April 25, 2008  
Blogger Henrik Nyh said...

Oh, someone said that already. I should reload more often.

3:11 AM, April 25, 2008  
Blogger Johnnie said...


I bet your programming chops would outrank mine even if you had to type with your elbows.

That said, I am going to advise you to put the macports down and walk the other direction. Go to your favorite terminal and type "port installed", note the output and prepend each line of that output with "sudo port uninstall".

Macports is a dangerous game and at some point will bork your system. You'll type "sudo perl -MCPAN -e shell" and find that your PERL updates are updating the PERL in the macports tree which pretty much renders your /System/Library/Perl useless.

Even if you don't use PERL and its packages, you are practically guaranteed to find one day a piece of software that macports will be unable to properly compile/install. You'll then discover that tracking the problem (let alone fixing it) akin to trying to separate coils of scat according to origin, but there you will be with you massive macports tree unable to back out of the "pile" macports has left behind.

Leave macports as soon and quickly as you can or keep what you have but compile/install from source from here on out.

I don't mean to sound sanctimonious, so if I do ignore my tone but consider the content. Beware macports.

Oh, and welcome to the platform (though you've been here for a while it seems). I look forward to future posts where you pit the power of preference against the power of The One True Way™.

3:15 AM, April 25, 2008  
Blogger pm215 said...

Incidentally, for Windows I prefer TXMouse over the tweakUI behaviour, because MS also didn't quite get focus-follows-mouse right. With TweakUI the focus follows the mouse but you can't send a mouse event to a background window without it automatically foregrounding it. Plus TXMouse gives you a pretty good impression of X-style mouse-only cut-n-paste. Shame the TXMouse source code isn't available :-(

3:34 AM, April 25, 2008  
Blogger Ulysses said...

A suitable hack might be:
- On keyboard input, find the window it belongs to
- if it's not in your app, raise that window, wait an instant, and fire the keyboard event at it
- after a short delay, or mouse exiting the window, push the window back down to its original location

Of course, I have no experience with the OS X's APIs, so this is a comment from the peanut gallery.

3:47 AM, April 25, 2008  
Blogger lisper001 said...

Windows doesn't have a decent media player!

3:51 AM, April 25, 2008  
Blogger Sitsofe said...

Hmm definitive proof that all the cool Unix cats (who don't have to dogfood) use OSX as their desktop. Strangely this focus-follows-mouse issue keeps coming up from a couple of switchers ( Val Henson mentions it too over on ).

I thought maybe in 10.5 might give a clue (as that has focus follow support) but it is only between its own windows. It transfers keypresses like Ctrl-S but you see it actually focusing the other window (but it doesn't autoraise it).

With regard to quietly fixing legacy apps, after reading Raymond Chen's oldnewthing it seems MS are especially talented and shimming old apps to keep them working ( is about having to build a fake control panel). However isn't the benefit to other desktop OS companies that they can break backwards compatibility to avoid massive maintenance costs?

The one thing I've noticed though is that if you want to make the fonts bigger (because you aren't as keenly sighted as Stevey) in OSX you will find that it's a per app setting. Yes there's screen zoom but that's not the same and other OSes seemingly make it easier to ramp fonts up across the board in one go...

3:52 AM, April 25, 2008  
Blogger Steve Yegge said...

Eritreo: your opinion is inextricably intertwined with a logical fallacy.

Specifically, you're saying that the OS X UI design is (a) "right" for all users, and (b) has not made any mistakes.

Put another way, you're saying Apple did it "right", with no room for argument.

The fallacy is that if Apple really got it now-and-forever "right", then they would never need another software release. Each time they release software, they're admitting, in effect, that they got it at least partly wrong before.

Case in point: Leopard finally added a System Preferences option for swapping Caps and Control, which was historically nearly as big an annoyance as the lack of autofocus.

If I'd written my article about swapping Caps and Control, you'd likely have made the same comment -- but Apple, with the Leopard release, is for all intents officially declaring you, Eritreo, to be mistaken.

So think with a little more care next time.

3:53 AM, April 25, 2008  
Blogger noir said...

Although I never owned anything but a Mac, I too get annoyed occasionally with the BONK, BONK. This happens however because I don't even think about which window has focus or where my cursor is. I just look into a window and start typing. My wish to the Apple fairy therefore is for focus to follow my visual focus. Just use the webcam to figure out which window or textbox I am focussing on and move the cursor there.

It might not be possible yet (and sunglasses will pose a problem) but I often will start doodling with my cursor and it then can be anywhere when I start typing.

And yes, this probably won't work in practice. Imaging copying text from a bitmap image by looking at the image and typing into a different window (as spam protection for this comment requires).

4:05 AM, April 25, 2008  
Blogger private said...

steve yegge said... "do you honestly think I don't know about MondoMouse? I researched the ever-loving crap out of this topic. And do you think I'd pay fifteen bucks for something I can make my own application do for me?"

Please explain to me how MondoMouse does not meet your needs? I don't know anything about that program, but from what you wrote in your article and what I read on MondoMouse's website about what the program does, it sounds like it does exactly what you're asking for. I'm not being snarky, I'm just trying to understand the issue here.

4:32 AM, April 25, 2008  
Blogger David Avraamides said...

Steve Yegge said:
> david avraamides: the article clearly says X11 already supports focus-follows-mouse. Thanks for sharing! is not an X11 app. Thanks for actually reading my comment.

4:41 AM, April 25, 2008  
Blogger snarkout said...

Steve, the reason CGPostKeyboardEvent looks like that is because it doesn't work quite the way you think it does -- the "Z" there represents a literal press of the key to the immediate right of the left shift key. That's a "z" on the standard QWERTY keyboard, but it doesn't actually need to be. The model for producing keys is somewhat insane, and your hack will potentially break for someone using a Dvorak keyboard. If you want to make it work in a more general case, you'll have to pay attention to what their current keyboard layout is; there are some open source examples of how to do this out there. (All of them that I know of require using some Carbon.)

4:45 AM, April 25, 2008  
Blogger David said...

Re linux font rendering:

Note that certain aspects of font rendering are restricted by apple-held software patents in the USA - "hinting" as discussed at that link matters particularly for font rendering at smaller sizes.

On linux, particularly if you're using a linux distro whose publishers feel they have to fret about US laws (remember the sheer idiocy of many US laws...), you may* get better font rendering by recompiling freetype to turn on patent-infringing interpretation of the manual hints, but in principle apple may then have grounds to sue you if you're in the US.

(* depends on somewhat subjective preferences and the particular font - the autohinter can work better than manual hinting, manual hinting depends on the font creator...)

5:07 AM, April 25, 2008  
Blogger df0 said...

Keyboard input following the mouse position sounds like one of the worst things you could ever do to usability.
Sounds more like your used to a bad behaviour rather than you actually need this.

I think quicksilver would be a better investment to send terminal commands

5:07 AM, April 25, 2008  
Blogger ww said...

Both focus-follow-mouse and the menu bar are issues that bug me, too. But aren't they mutually exclusive in terms of interoperability? If you have focus-follow-mouse and rollover a partially obscured window, wouldn't the menu bar change to the new app? It seems to me that just getting to the menu bar for app A would risk changing the menu bar to something non app A.

5:23 AM, April 25, 2008  
Anonymous Anonymous said...

Leopard finally added a System Preferences option for swapping Caps and Control, which was historically nearly as big an annoyance as the lack of autofocus.

Just to be pedantic, this was actually added in Tiger (OS X 10.4).

5:31 AM, April 25, 2008  
Blogger daemian said...

Interesting article.

I've long had a problem related to this. I got very used to focus-follows-mouse under Linux, and switching back to Windows on the desktop (largely as a nice Linux shell, as you phrase it) meant I had to resort to TweakUI.

(TweakUI allows both modes of focus-follows-mouse, incidentally -- auto-raise and non-auto-raise -- and both work great, despite some earlier commentary to the contrary... though it troubles me to call auto-raise 'great'.)

My problem is that, although TweakUI works wonderfully, it turns out that it kind of breaks "cool-switching" -- the use of Alt+Tab to switch among active applications.

In a non-focus-follows-mouse world, the first option when hitting Alt+Tab is to switch back to whatever application you were working in last. So you really don't have to read the list of options at all, to pop back to your last app -- just hit Alt+Tab, let go, and there you are. This makes for a workflow that is really effective at high-speed task-switching between a couple of programs.

But with focus-follows-mouse, it becomes clear that Windows populates the list of Alt+Tab options based on what window was last clicked, not what window last had focus. So now you've got a situation where when you go to Alt+Tab, you can find what appears to be an almost randomly sorted list of applications.

I used to use the keyboard for everything, but a combination of Linux (well, X, with its focus-on-mouse) and Windows' weird Alt+Tab mechanics has actually driven me away from the keyboard, since I end up having to cycle through Alt+Tab so much to get to my desired application that it's faster just to keep my hand on the mouse.

If anyone hasn't fallen asleep yet, and knows of a fix, I'd pay in my own personal blood to read of it.

5:35 AM, April 25, 2008  
Blogger David said...

You didn't really spell out what I consider an important point: difference between "sloppy" (yay...) and "strict" (gaah...) focus follows mouse.

In typical X11 focus-follows-mouse, the following is what is traditionally called "sloppy" - the user explicitly moving the mouse pointer to enter a window shifts the focus to the window, but moving the mouse pointer out of the window doesn't cause that window to lose focus until the mouse pointer is moved into another window, it's the gesture of the mouse pointer being moved by the user into a window that moves the focus, not that windows only have focus if the mouse pointer is in them.

5:48 AM, April 25, 2008  
Blogger Mo said...

This is horribly hacky, but you could make use of the Input Manager stuff to solve part of the problem. Ignore the earlier comments about APE being the One True Way; it isn't—it's broken. The methods APE uses might work for you, maybe, though. Input Manager hacks are pretty bad, but I get the distinct impression this is largely for your own benefit, which is good, ‘cos in general arbitrary injection of keyboard events into applications is less than ideal.

Presented with the problem of “how to hook other applications without using the impotent accessibility APIs”, I'd build an Input Manager [or something along those lines] which duly gets loaded into GUI apps and connects to a Mach port, listening for instructions. Meanwhile, in per-user launchd land, write a daemon which listens on said Mach port, for short messages containing an application identifier of some kind and keyboard event details. Your daemon duly passes the event onto the appropriate listening app, where your Input Manager picks up the ball and injects the events in the context of the target application.

Of course, I've made it sound a lot easier than it actually is, and I haven't tried any of this… but in the absence of an API that works it strikes me as the only really logical way to accomplish it—once you can inject code into your applications, you can do anything with them, after all.

5:51 AM, April 25, 2008  
Blogger Brian H said...

Here's a tip, don't use a mouse (for much). The only thing I use a mouse for is copy and paste, focusing some UI control that is too many TABs away from the currently-focused control, and the 2-finger scroll on a MacBook Pro (which is really stellar).

5:57 AM, April 25, 2008  
Blogger Amorya said...

In Cocoa, I believe there's a difference between - (void)makeKeyWindow and - (void)makeKeyAndOrderFront:(id)sender.

(There's also just orderFront, which brings a window to the front without giving it keyboard focus).

Now, I haven't tried this, but you might be able to make an input manager plugin that sends makeKeyWindow whenever a mouse enters a window. That'll not clash with the menubar issue, because the window will have true focus. Its titlebar will turn grey, and the menubar will switch. It just won't come to the front.

Have a look at -- I know that's only implemented within one app, but you could presumably do something system wide. It'd only work for Cocoa apps, but most apps are these days.


5:58 AM, April 25, 2008  
Blogger Amorya said...

In Cocoa, I believe there's a difference between - (void)makeKeyWindow and - (void)makeKeyAndOrderFront:(id)sender.

(There's also just orderFront, which brings a window to the front without giving it keyboard focus).

Now, I haven't tried this, but you might be able to make an input manager plugin that sends makeKeyWindow whenever a mouse enters a window. That'll not clash with the menubar issue, because the window will have true focus. Its titlebar will turn grey, and the menubar will switch. It just won't come to the front.

Have a look at -- I know that's only implemented within one app, but you could presumably do something system wide. It'd only work for Cocoa apps, but most apps are these days.


5:59 AM, April 25, 2008  
Blogger Reinier Zwitserloot said...

I've never been a big X user and as such I've never really done the focus-follows-mouse thing. However, I am intrigued. I turned it on for terminal and so far I likes.

So here's my attempt at being helpful:

I'm fairly sure there's some way to activate a window, actually make it the 'front', active window, WITHOUT raising it to the front in the GUI. Just like terminal does it.

This isn't optimal, because, amongst other things, you can now no longer browse the menu of an app with the mouse unless there's a path from the window to the menubar that does not cross any other windows. Perhaps hack around this by refocussing the app whose GUI element is frontmost just before you hit the menu area.

And a general note, there are a number of GUI hack tools out there, and they just about always require you to turn assistive support on. Now that I know that root will do the trick too, I'd be much happier if these tools can just be configured with +s instead of forcing me to open that hole for all apps.

6:05 AM, April 25, 2008  
Anonymous Anonymous said...

I believe someone referred to this in a previous comment (maybe Steve), but there's a key difference on the Mac between an APPLICATION being frontmost and a WINDOW being frontmost.

Using simple UI scripting in AppleScript, I can pretty well fully control a background window. Modifier keys become a little goofy -- I can send a modified KEYSTROKE to the background window (for example, an option + key to make a special character, or shift + key) or move the cursor in a text area (again, using keyboard commands), but actually executing keyboard shortcuts (save, etc.) won't work since the application is designed so that those commands specifically affect the front window.

I was also able to mock up a very painful prototype of a script that calls a given APPLICATION to the front, but preserves (well, re-establishes) window layering afterward. It's ugly and requires looping through every open window, but it seems to work (Again, I'm using AppleScript, so my options are limited)

From there I can use UI scripting (which also leverages the accessibility APIs) to send stuff to that background window.

So I wonder if the trick here might be to bring that background application to the front when the mouse focuses on its window, but keep all the windows where they are.

This would be problematic on programs that (incorrectly) follow the MacOS Classic approach of bringing all of an app's windows to the front when any one of its windows are activated, but I guess those apps just suck.

Or maybe this is already obvious and how you're doing it now. In which case, sorry for wasting your time.

6:14 AM, April 25, 2008  
Blogger jonahan said...

Just use spaces and put each app in it's own friggin window.. Problem solved.

6:18 AM, April 25, 2008  
Blogger Shane said...

I have another BLONK BLONK issue: why can't Apple admit that Home/End keys (and the shift modifiers for selection) should work as nature intended? I.e., go to the start/end of a line.

Yes, there are 3rd party apps like DoubleCommand that almost work, and Emacs-like multi-finger variants, but this behavior is SO commonly needed it demands single key solutions. Windows and Linux implement this correctly.

Like Steve's focus issue, there is always some religious reason (the docs say it should do this, so it must be correct!) why the default Mac behavior is better. Feh.

6:25 AM, April 25, 2008  
Blogger Kirk said...

From a completely different perspective: As an IT professional - the operations perspective, not the software development side - the consistency of delivery, uniformity of approach, and standard UI conventions radically reduce the support and training costs of a Mac environment over any other currently available platform.

This "have it your way" approach, has created the extreme diversity of application interfaces, and even hardware support of the Windows world, making the life cycle cost of Windows 3-10x more than a Mac.

I don't speak out of platform fanaticism - I was taught long ago the phrase "In GOD we trust, all others bring data". My empirical data set in this regard spans over 262,000 desktops at a single company, with cost tracking of each platform's support comprehensive. This has been validated with data from multiple other companies as well.

What you describe is a significant reason that LINUX will never get a major role in user desktops - the support cost of the diversity of approaches is too high. If Microsoft had not engineered major barriers to migration (data format lock in) in virtually all their products, mass migration off the exceedingly expensive Windows platform would have started years ago.

Maybe it is your age - not wanting to learn new things, proven approaches, etc. :-) - the first barrier to innovation.

There are very sound reasons for Apple having done it the way they have, from a usability consistency perspective. If programmers had access to, say, alternative approaches to the open and save dialog boxes, you might get something as screwed up as, say, Microsoft Office on Windows, where no 2 products in the family have the same look and feel or even functionality - to say nothing about even the lack of availability of the same tools across Office products.

6:27 AM, April 25, 2008  
Blogger Kirk said...

One other point - a "prime directive" of sorts in Apple's Human Interface Guidelines..... it has been some years since I have read it (before you were in the industry), so the content is paraphrased.

The computer will never take over control of the user input function. A user must explicitly direct the user input control and function.

e.g. Where you place the cursor is where the cursor is, not where some program things it should be.

6:34 AM, April 25, 2008  
Blogger Shane said...


> e.g. Where you place the cursor is where the
> cursor is, not where some program things it
> should be.

I wish it was that simple.

Go to a web page, click in the browser URL bar, hit the End key.

The browser will scroll the body pane to the bottom.

I have explicitly changed the focus to the URL bar, but the program has intervened on my behalf. So much for biblical interpretations of behavior.

6:41 AM, April 25, 2008  
Blogger fugalh said...

I didn't read all the comments, but I did read the article.

I came from Linux as a die-hard sloppy focus user to a Mac laptop. At first I dual booted and spent a lot of time in Linux (and getting it working on my iBook). Linux on a mac laptop is a bit shaky because of that stupid one-button trackpad. If you think living without sloppy focus is bad, try surviving in Linux with one mouse button.

So I gravitated more and more to OS X and yes I missed sloppy focus. I still do. I'm glad you're bringing it to the foreground and I hope you or someone can eventually get a workable solution.

But in the process of coping, I found an unexpected gem. OS X keyboard shortcuts are more ubiquitous and more consistent than in Linux, and this makes using OS X with minimal mousing not only viable but actually better than in Linux.

If you're stuck on OS X (by your choice or someone else's), then in the absence of sloppy focus take the time to learn how to leverage that keyboard. It won't be quite the same, but it will help.

My favs, cmd-h, cmd-w, cmd-m, cmd-tab, cmd-`, and ctrl-space (quicksilver).

6:53 AM, April 25, 2008  
Blogger Tim said...

Have you looked at Codetek Virtual Desktop? It offers focus-follows-mouse without autoraise. I haven't used it, but the site seems to suggest that it's a system-wide feature.

6:56 AM, April 25, 2008  
Blogger Capt. Miraculo said...

First, great post.
Have to admit I'm a little chagrined by the quality of posts you have received so far. There are some really great programmers on the Mac and most of the comments are more concerned with pointless suggestions or telling you you shouldn't bother, exactly the things you highlighted - before they even posted!!
Anyway, the Mac is a 'user-friendly' computer which accounts, no doubt, for the largely non-technical audiences. Heh.
I think the focus follows mouse issue is a very hard one to get Apple moving on because it could be (and I'm sure you'll agree with me on this) quite confusing for non-technical users. Apple was very careful to make 'magic' type functions - Spaces, Exposé, Dashboard etc. - get obvious visual queues so people can quickly understand what it's doing. But what are the visual queues for focus follows mouse?? Minimal, and with no clear way to make it more obvious (for non-technical people).
Here's hoping... and again I'm shocked (and I mean shocked unfortunately) that no one has suggested you raise a bug. It's almost always the first thing that comes up on the mailing lists I frequent.

Anyway, welcome to the smoothest UNIX you've ever tasted,

6:56 AM, April 25, 2008  
Anonymous Anonymous said...

Steve, you should put those old Windows machines to good use and say "Goodbye Microsoft" the right way. ;)

But seriously, as another comment above mentions, Linux fonts with hinting enabled actually looks nice. It could be that I'm just used to how it looks now, but I much prefer it to the MS Windows pixelated look.

6:56 AM, April 25, 2008  
Anonymous Anonymous said...

Kirk, Linux has tools that will let you lock down a bunch of machines any way you like. That is a much better approach to the problem than going with a restrictive OS to make life easier for the admins.

6:58 AM, April 25, 2008  
Blogger Josh Farkas - Water Media said...

Very nice article,

But I'd have to say 3 days into the ability to code for any OS will lead to frustration in looking to create your own solution.

If there is a big enough need, time has shown that someone will find a way to create this and release it for others.

If there isn't a big enough need then this issue won't be solved. Plain and simple.

(I'd agree that spaces or cmd+tab handle this problem in a different way. Or run parallels with an open linux window.)

7:07 AM, April 25, 2008  
Blogger Pete said...

Another ex-Linux user adding a me too, in case Steve Jobs is reading:


The accessibility controls really feel half-assed. Have you tried increasing the cursor size? Pixel-riffic.

7:11 AM, April 25, 2008  
Blogger Morten Johan said...

So you find that Carbon has a cumbersome C-based API, and then you go and blame C++? :)

7:17 AM, April 25, 2008  
Blogger The Tramp said...

So, in various Unix flavours I prefer sloppy focus, but only just. What I really really would like is click-to-focus-but-not-auto-raise.

I concede that my preference may be perhaps the smallest minority :-)

7:19 AM, April 25, 2008  
Blogger Peter Cooper said...

That's all there is to it. This is the solution I envisioned before I'd even downloaded Xcode, and unsurprisingly, it appears to be the only reasonable way to accomplish the task in OS X. I mean, how else would you do it?

I had a rough idea in my head of how I'd go about it and was surprised to read your technique.. so perhaps there are multiple ways (although I certainly haven't tried mine!)

My idea would be to track the mouse, as you have, but NOT to capture the keyboard at all. Instead I would try to find some way to give an application focus /without/ raising it to the top, when the mouse was in the correct place. Then I'd let the regular keyboard handler for that application deal with the keyboard. No broken keys, etc.

Amorya (above) wrote pretty much what I was thinking of. It all depends, however, whether makeKeyWindow gives a window focus without raising it, but I'd be surprised if there isn't a way, since you can certainly raise a window WITHOUT giving it focus.

One cute trick is to be in another app, hold down the Cmd key, then go interact with another program while holding down the key. You can do quite a lot without giving the other app keyboard focus, even paste stuff into it. So I'd suspect there's a clever way to get the inverse result..

7:23 AM, April 25, 2008  
Blogger cmore said...

This comment has been removed by the author.

7:26 AM, April 25, 2008  
Blogger cmore said...

[fixed typo]

Have you looked at code for CloneKeys (available on googlecode)? It broadcasts keystrokes to both the frontmost application and to all the background applications, and it seems to have no problems with modifier keys. I think it has extra code to track the state of modifier keys, so it might have some of what you need.

7:28 AM, April 25, 2008  
Blogger Ahruman said...

“These AXUIElementRef objects have all their information in property lists. This would be trivial to navigate in RubyCocoa, but the AXUI API set doesn't seem to exist in Cocoa”

It’s worth noting that you can cast a CoreFoundation property list type to the corresponding Cocoa object pointer type, then use Objective-C with semi-automatic memory management to work with it. I believe you can also get at C functions from RubyCocoa, so you should be able to use this approach there.

“This cousin function has a teeny bit of explanation in its header file CGRemoteOperation.h, which Xcode provides no easy way of locating via search. You can look for it in Spotlight, hoping you'll get lucky and it won't hang like it did for me just now. Or you can do what I did and just use Google Desktop search to pop to it instantly.”

The command in Xcode is File->Open Quickly, which in Xcode 3 allows you to type a file name or a symbol. The ability to search for symbols here is non-obvious, but *mumbleMumbleNDAedBetaEasilyAvailableMumbleJuneMumble*.

You can also command-double-click any symbol to jump to its definition or declaration (and option-double-click to jump to documentation).

7:34 AM, April 25, 2008  
Blogger David said...


"Another thing is Apple's UI is application-oriented, not window oriented. I highly recommend the use of Cmd-H to hide applications when you are 'done' with them. I never ever minimize windows."

Can someone please email Adobe and remind them that this is supposed to work like this.

8:00 AM, April 25, 2008  
Anonymous Anonymous said...

Although not as useful as what you're talking about, you can interact with background windows via the mouse by command-clicking on them. This isn't a solution to your problem, but is evidence that Apple has at least given some consideration to it.

Focus-follows-mouse and other UI conventions like that are not unlike conventions in the physical world, like the infuriating habit of American car companies that put their gear shifter on the steering column instead of down beside the seat. If you grow up with one, you're not always easily swayed by the merits of the other.

I've seen many implementations of the focus feature as a friend of mine, an old UNIX user, had much the same opinion as you do, that working without it was a life less fulfilling. There's always something that gets in the way of the 'perfect' solution, too.

The only way that it will ever work is if you're able to wrangle the menu to the foreground for the reasons you've described, yet still preserve the z-index of the windows themselves.

A lot of applications have triggers when they're pushed into the foreground, though. For example Adobe's products make their various toolbars visible only when in the foreground and hide them automatically when in the background. The focus extension would likely trigger this behavior, too, unless you manage to focus-but-not-focus somehow, and I'm sure that's a recipe for disaster.

I hope you can find a solution, though, because I know a lot of people that want that very thing.

8:31 AM, April 25, 2008  
Blogger mike said...

There's a company called "Unsanity" that made an app for workspaces on OS X before leopard came along with spaces. One of the side effects of using it was that it gave you the option of setting window focus to autoraise. I know because I used it. Then I discovered that OS X lets you do all kinds of things with windows that don't have focus (raise volume in iTunes, scroll, some apps let you drag preselected text, etc.) so I stopped using it.

8:35 AM, April 25, 2008  
Blogger Cable Ray Wire said...

Regarding my earlier comment, what I meant to say was applescript can access some accessibility API calls. AppleScript in general can only do some of the things other APIs can do. I meant this as a general suggestion, and not necessarily as something that would help your project. You never said weather or not you tried it, or if it worked. I figured you might have, but thought I'd mention it for the benefit of people who read comments. Sorry I wasn't more clear, and didn't check for the specific API calls needed. But it looks like most of the necessary calls are there, as mentioned by nik.

10:00 AM, April 25, 2008  
Blogger Russell Finn said...

If long-time Mac users are so ready to insist that the Mac way is the *right* way to do things, it's partly because the outsiders and newcomers are so quick to insist that the Mac way is the *wrong* way.

I don't mean Steve, necessarily, who seems to understand that the Mac behavior is merely different from what he's learned, not better or worse. I have in mind people like -- well, let me pick on Shane for a moment:

why can't Apple admit that Home/End keys (and the shift modifiers for selection) should work as nature intended? I.e., go to the start/end of a line.

... Windows and Linux implement this correctly.

... there is always some religious reason (the docs say it should do this, so it must be correct!) why the default Mac behavior is better. Feh.

Hey, Shane? The Mac UI predates both Windows and Linux, so who are you to say what nature intended? I say Windows and Linux do it wrong. Nyeah. :-)

Go to a web page, click in the browser URL bar, hit the End key. The browser will scroll the body pane to the bottom.

... because that's what Home and End (and Page Up and Page Down) do in the Mac UI -- they scroll the window, not move the insertion point.

I imagine if you poke around you can find utilities to change this behavior, but don't insist that your own personal experience defines how everyone should behave. (Hey, where have I heard that before? You Maclots, pay attention, too.)

10:08 AM, April 25, 2008  
Blogger Matt Campbell said...

This isn't about focus-follows-mouse, but it is about a topic that you discussed in this post: the effectiveness of an accessibility API. I'm a Windows assistive technology developer, so I may have an interesting perspective on this.

I believe that even for assistive technolgoy developers, a UI that's open to inspection and manipulation by outside programs (running at equal or grater privilege level than the app they're working with) is much better than an accessibility API added to a UI that's locked-down or opaque to outside programs. To illustrate this point, I'd like to contrast two types of rich web application from an AT developer's point of view: DHTML under IE, and Flash.

This may upset some readers (and maybe Stevey himself), but I've found that IE is a Windows AT developer's dream, because the full DOM can be inspected and manipulated via COM (again, by apps with equal or higher privilege level relative to the browser). Granted, a similar level of access to FIrefox could be achieved by installing a Firefox extension, but this is a real annoyance, especially if you're running a screen reader or other AT on someone else's machine (using a thumb drive, for instance). Anyway, my point is that since the complete DOM can be inspected and manipulated by outside programs such as AT, the possibilities for making HTML-based web sites and apps accessible are nearly limitless (with visual-only CAPTCHA being a major exception). We're not dependent on web designers or developers to make their sites accessible by implementing accessibility guidelines; even when site-specific hacks are required, we can still make things work.

Contrast this with Flash. I don't know what the situation is on Mac or Linux, but on Windows, Flash implements Microsofot Active Accessibility, and that's all we have to work with. Even if Flash implemented a richer accessibility API such as UI Automation or IAccessible2, that would only be useful if Flash apps followed accessibility guidelines. I can tell you from experience that many (most?) Flash apps don't even reach the limit of what's possible with MSAA. However, if Flash Player exposed a complete object model -- the Flash equivalent of the DOM -- that would be invaluable to AT developers, and perhaps to others wanting to do interesting UI tricks.

Anyway, my point is that an accessibility API is often not enough even for the assistive technologies it aims to support. This is in part because, as Steve said, a platform's accessibility API is usually developed to stay on the right side of the law or get government purchases, not out of any real concern for blind people and others with disabilities. But I think the bigger problem is that many apps and web sites, especially those developed by startups, just won't follow the rules of accessibility.

Complete access to a UI's native object model for outside programs (again, taking reasonable security considerations into account) is by far the best solution, both for accessibility and for niche UI features like focus-follows-mouse.

10:32 AM, April 25, 2008  
Blogger Shane said...

@russel finn

> The Mac UI predates both Windows and Linux,
> so who are you to say what nature intended? I
> say Windows and Linux do it wrong. Nyeah. :-)

My point was usability. I think most people would agree that they want to go to the start/end of a line much more often than start/end of a page. For me, at least 1000 to 1.

That's what I mean by how nature intended... the nature of people, not the nature of operating systems.

"Who came first" is meaningless.

> ... because that's what Home and End (and Page
> Up and Page Down) do in the Mac UI -- they
> scroll the window, not move the insertion point.

I've never understood circular arguments like this: "feature ABC must be the best way, because if it wasn't, the system would do it differently." Huh?

My argument is system agnostic, and based on usability considerations. What's yours?

10:37 AM, April 25, 2008  
Blogger Sean said...

The biggest thing that the "non-focus-follows-mouse users" are missing is that Steve (and I) want to be able to type into a partially-obscured window.

If I have PDF documentation open, and a terminal window, I don't have enough screen to have them open side-by-side (without zooming the PDF out until it is unreadable). The best solution is to have the PDF partially overlap the terminal window.

That way you can type into the terminal window, without covering up any of the PDF you're trying to read.

So, commenter, unless your solution allows you to type into one window that's partially obscured while looking at another window, it's not a solution.

10:42 AM, April 25, 2008  
Blogger Tech Worker said...

This comment has been removed by the author.

10:55 AM, April 25, 2008  
Blogger Tech Worker said...


When I used Windows and Linux, their Home/End behaviour bothered me tremendously. To say that those keys should act as you suggest because it is "natural" is simply untrue. I suspect that whichever behaviour one experiences first would be the one that seems "natural" to any given person. If Apple changed their behaviour, they would really cause a ruckus.

BTW, are you aware of cmd-left arrow and cmd-right arrow? If not, try those out for awhile. Although they won't be automatic for you as home/end are, they at least provide the same functionality.

10:57 AM, April 25, 2008  
Blogger Justin said...

I wish people would stop saying OSX is based on BSD. It's a compatibility layer that translates POSIX (a commonly used API) to a variation on the Mach kernel (not so popular). BSD can run Linux binaries thanks to a similar translation layer, but nobody intelligent runs out and declares BSD based on Linux.

11:13 AM, April 25, 2008  
Blogger Justin said...

Really, though I have no idea how big or fluid Google is internally, I'm surprised you didn't turn to the Googler who wrote the MacFUSE, Amit Singh. I recall a tech lecture wherein he describes the technical difficulties trying to create a /proc/ interface on OSX.

11:27 AM, April 25, 2008  
Blogger Phil said...

I'm all for getting better control over your UI, but is this really the best reason? What ever happened to "real programmers only touch the mouse as a last resort"?

11:28 AM, April 25, 2008  
Blogger Shane said...

This comment has been removed by the author.

11:39 AM, April 25, 2008  
Blogger Shane said...

@ tech worker

Like russell finn, you seem to rely on arguments from personal experience. Please talk to my point about real life usability. IOW, what would the best system be? Do you, or do you not want to go to the end of a line more than the end of a doc?

And consider the contexts (and there are many) where we're talking about single line UI elements where there is no notion of "end of document". In those cases home/end keys simply do nothing. What a waste!

And before you say "But that would be inconsistent behavior, think of the poor users!", I believe users can be dumb, but I refuse to believe if home/end worked in single line UI elements, user's heads would explode in a ball of flame of confusion.

11:45 AM, April 25, 2008  
Blogger Claire Connelly said...

@Johnnie -- the behavior you describe is the whole point of using MacPorts. It's a packaging system. Your advice is like telling someone running Red Hat Enterprise Linux to just compile their own source packages and install them over the top of the system-supplied code. Bad things will happen.

MacPorts maintains a completely separate set of software from the software installed by the OS. If you somehow screw something up, you can uninstall the port. If it's really broken, you can go in and zap the files or even the whole tree. If, on the other hand, you start replacing files installed by the system, you're definitely going to have issues down the line when some system code doesn't work properly because you've updated some underlying Perl, Python, Ruby, or other library.

MacPorts has ports for some significant number of Perl modules. Adding your own isn't that difficult.

There are things that (really) suck with MacPorts, but helping you avoid messing with Apple-installed software isn't one of them.

11:48 AM, April 25, 2008  
Blogger Marshall said...

@justin: The Mac OS X kernel (xnu) is a blend of code from both Mach and FreeBSD, and the command-line environment is almost entirely derived from FreeBSD and NetBSD sources. It is very much a BSD-based operating system.

12:17 PM, April 25, 2008  
Blogger Ethan Herdrick said...

>I suppose I could do a
>blow-by-blow guide for how a
>Unix-and-Windows user can configure
>their Mac for maximum happiness. If
>anyone's interested, anyway.

I'm very interested in this, especially from your Cygwin-and-Emacs perspective.

12:18 PM, April 25, 2008  
Blogger Julius said...

I just want to say this blog post was the most thrilling programming story I've ever read.

It's one thing to be the Jason Bourne of programmers. I figure there are a hundred or so of those in the world. But to actually be able to write about it!?!

The buffalo and the durian were brilliant. Even my wife smiled (I read it out loud to her).

12:26 PM, April 25, 2008  
Blogger Robert Fisher said...

"So you find that Carbon has a cumbersome C-based API, and then you go and blame C++? :)"

Actually, it started (back before it was called "Carbon") as a Pascal API. (^_^)

12:36 PM, April 25, 2008  
Blogger charles said...

Quite OT, but I will make it short: since you like RubyCocoa, and you seem to like Lisp, and since you are new to Mac developement, you may have not heard of it yet, but you might like Nu, a Lisp-based glue language specially designed to work with ObjC and Cocoa, see

12:43 PM, April 25, 2008  
Blogger ustunozgur said...

Have you tried Zooom?

12:56 PM, April 25, 2008  
Blogger Zack said...

It seems like very few commenters have sufficient experience with both environments, or are able to fully understand Steve's issue.

As a Mac user who came for the UNIX and stayed for the UI, I would like to apologize for all of these bozos. I hope you get what you want, Steve. I would like to have the option of true focus-follows-mouse as well.

As for the rest of you, is it so hard to read and understand what Steve wrote before responding? This is a larger problem than most of you realize, technically and culturally. The cacophony of useless suggestions is deafening.

I remember very well what a glorious day it was when Caps Lock -> Control was officially implemented in OS X. I think there's hope for old UNIX users on the Mac, but only if we raise the issue like Steve is doing here. As he has rightly pointed out, the current UI paradigm would need to be, er, widened a bit to make room for this capability.

1:05 PM, April 25, 2008  
Blogger Sigivald said...

Beyond what Johnnie said, I imagine you don't mean to imply that you need to install MacPorts to get bash, ssh, and emacs, all of which come with OSX.

(At least if you bother to install the bsd subsystem stuff, and possibly the devel toolkit, which you obviously would if you wanted to compile MacPorts anyway...)

1:46 PM, April 25, 2008  
Blogger Sigivald said...

Justin: You might remember that part of the reason people say "OSX is based on BSD" is that Apple calls the optional, installable userland stuff the "BSD Subsystem", and Apple says outright that Darwin is "built on Mach 3.0 and FreeBSD 5".

In other words, people say it because it's true - if not in every possible interpretation of the words, then at least in some obvious and straightforward ones.

Shane: Try up-arrow and down-arrow for start and end of a textbox. That's just as "natural" as home/end, if not moreso, since "home" and "end" are grouped on the keyboard with "page up" and "page down", thus associating them, physically, with the document.

There's no "natural" reason that "end" must mean "end of line" rather than "end of document"; it's merely what one is used to.

I don't mind home/end moving one on the line (because I never use home or end), but I'm constantly annoyed by windows not being Mac-like in its handling of textboxes and the arrow keys.

(And I'm a Windows developer for a living, and just use Macs at home, for daily computing.)

2:02 PM, April 25, 2008  
Blogger dete said...

I'm not personally motivated to implement focus-follows-mouse, but it seems to me that the following should be feasible:

1 - Implement an autoraise daemon. (Yes, autoraise sucks hard, but don't judge me until you've read step two!)

2 - Manipulate the window levels of all open applications so that the z-order doesn't change when the focus changes. (The NSWindow docs explain it here, but the concept applies to non-Cocoa windows just as well.)

OS X is quite happy focusing on windows that aren't foremost, so long as the windows in front of the focussed window have a higher level value (and yes, they can belong to other applications).

I foresee four potential problems:

1 - Since you'd actually be activating the background applications, the menu bar would flicker as you moved your mouse. The menubar is just another window, though, so I believe you could work around this by manipulating the menubar's window level.

2 - OS X applications are notified when they are activated/deactivated, and some apps do non-trivial processing when this happens. This is especially noticeable when you start swapping. I don't think there is any way to "fix" this, but waiting until the mouse stops moving for a short period (1/10th of a second?) before focussing on a particular window/application would certainly mitigate the problem.

3 - The Finder's Desktop is a window. This will be a problem if you are used to flicking a mouse into a window to assign it focus and then flicking into "empty space", getting the pointer out of the way while leaving focus. Should be easy to filter this out. More difficult might be to figure out which windows you don't ever want to focus too: the dock, various overlays (check for click-through?), etc.

4 - Most multi-document Mac applications run just fine without any windows open. If you were to try to command-tab to one of these, you'd switch out again before the mouse ever got to the menubar! Perhaps this could be fixed with the same trick I suggest for problem #1?

If you want extra points, you could even reduce the opacity of windows in front of the one with focus. With that feature, you might even win some converts from folks like me who don't much miss focus-follows-mouse.

2:36 PM, April 25, 2008  
Blogger Steve Yegge said...

Wow, so many comments! The quality is definitely going up. I guess this makes sense: people who take the time to read and think take longer to get their comments posted.

To everyone (esp. amarya) leading me towards the "change focus but keep Z-order" approach -- this is very, very promising, and hopefully I can find another couple of days to poke at it in the next few weeks.

The CodeTek product claims to do it, but they don't yet work on Leopard (though they tell me it's coming out soon.) I'll definitely be trying it when it's ready. So far, I've heard conflicting reports about what behavior it actually supports.

Folks who point out that this argument is really about accessibility, which trumps all other opinions and considerations: you're right. And Apple's not going a good enough job of it. Windows does it better. But the government really does need to mandate more openness or it seems unlikely to improve on the Mac, given how perfunctory their initial implementation seems to be.

To everyone who insists on debating the utility, usability or desirability of autofocus without autoraise: it sounds to me like you'd have debated the utility of any UI enhancement, including Spaces, Expose and the whole long list of OS X innovations preceding them. This means all I have to do is wait patiently for my feature to be provided by Apple, and then you'll all love it. Problem solved!

To all the Mac fanatics who seem to be viewing my article as a personal assault on the Holy Land: wow, how exciting! I never expected that I would expose yet another blind, raging, vehement fundamentalist religious software faction with this little article. I thought editors and programming languages were pretty much the last holdouts in our otherwise kind-of-enlightened society. This is great! It gives me a whole new source of jokes. Thank you for smoking.

3:11 PM, April 25, 2008  
Blogger Ethan Herdrick said...

Also: are you using Aquamacs? Keep us updated. Thanks!

3:14 PM, April 25, 2008  
Blogger Steve Yegge said...

One more important point: I'm surprised that some people seem to think I'm implying some programming studliness from my little 3-day excursion. Not so: any first-year college student or intern, or heck, self-taught dude in his basement, could have done exactly what I did.

I failed utterly to convey the right point here, by unfortunately being way too subtle about it. The recounting of total hours spent was a hats-off compliment to Apple for having written such great APIs, documentation, and tools.

Let me be clearer about it, then: Apple's development environment is nothing short of amazing, which I fully expected, knowing it derived originally from NeXTStep and has had fifteen or twenty years of innovations piled on.

The APIs are _clean_. This is why I was able to narrow down the APIs I needed so quickly.

The whole thing I got working was no more than 50 lines of code, most of it error-handling. That's C code, so it's impressive how much it accomplishes in so little space.

The takeaway here is that more programmers ought to jump in and start playing with OS X. You get results faster than you'd think.

3:20 PM, April 25, 2008  
Blogger Nick Valvo said...

Blacktree's Quicksilver may be your friend here for many of the non-focus switching tasks you seem to want to do, although it doesn't sound like you're all that interested in learning new styles.

4:09 PM, April 25, 2008  
Blogger David said...

@ the tramp:

KDE's kwin wm on X11 allows a click-to-focus-without-click-to-raise configuration (though it's not the default). It also supports the action being different depending on whether you click on the titlebar+frame of the window or the innards, which is handy for when you do want to raise the window - e.g. clicking the innards just activates the window, while clicking the titlebar activates and raises.

It also supports a delay timer (in milliseconds) for the focus-follows-mouse and autoraise features, so that you can choose to have to deliberately dwell the mouse pointer for a tiny bit in a window for them to kick in - which, hey, I guess could be handy for when you are "just passing through" another window on the way to a mac-style top-of-screen menu-bar*.

* supported by KDE for KDE apps at least.

(Bah. I dislike top-of-screen menus anyway (except maybe for keyboard use) - one of the first things I used to do on Amigas (which used top-of-screen menus) was install MagicMenu which added a nice "popup the menu whereever the mouse currently is" option)

4:33 PM, April 25, 2008  
Blogger noir said...

Just a quick question on how many BONKS people get because of autofocus. I played a little bit with autofocus in While it is very cool, I tend, as I mentioned before, to doodle a lot with the mouse which includes checking items in the menubar (eg, the battery status) and my cursor often ends up in a random position on my screen. I would probably get a lot of typing-in-the-wrong-window with autofocus enabled for all applications.

I understand the usefulness of being able to type into partially obscured windows, a useful addition for me therefore would be to focus a window when clicking with a modifier key.

4:45 PM, April 25, 2008  
Blogger aid said...

Steve, a problem. Although your high level thoughts on how to route your keys state that you send the redirected key message through to the window over which your mousing is located the actual API available - AXUIElementPostKeyboardEvent - sends the event to the *application* not to the original element that you first discovered.

When I tried to recreate your program, although in a slightly different manner, I found that I could redirect keys, but only to front-most window of a non-focused application. Importantly not the window one I was currently hovering over.

Once upon a time I live within Acorn's RiscOS operating system. It was standard on there for the right mouse button (named Adjust) when clicked in a window to place the focus on that window but without changing the Z order. Perhaps a nice possible implementation for OSX?

5:28 PM, April 25, 2008  
Blogger Dan Lewis said...

An interview with Knuth just came out the other day. He uses Ubuntu with FVWM and focus-follows-mouse.

I currently use Ubuntu Linux, on a standalone laptop—it has no Internet connection. I occasionally carry flash memory drives between this machine and the Macs that I use for network surfing and graphics; but I trust my family jewels only to Linux. Incidentally, with Linux I much prefer the keyboard focus that I can get with classic FVWM to the GNOME and KDE environments that other people seem to like better. To each his own.

9:04 AM, April 26, 2008  
Blogger sjk said...

> The CodeTek product claims to do it, but they don't yet work on Leopard (though they tell me it's coming out soon.) I'll definitely be trying it when it's ready.

Good luck with that. CodeTek never released a Tiger-compatible version of Virtual Desktop Pro that was supposedly "coming out soon". Have you read some of the customer comments on MacUpdate/VersionTracker?

> So far, I've heard conflicting reports about what behavior it actually supports.

I enabled focus follows mouse in the Panther version for a bit and it quickly became intolerable. If I remember correctly, it suffered from what ww mentioned:

If you have focus-follow-mouse and rollover a partially obscured window, wouldn't the menu bar change to the new app? It seems to me that just getting to the menu bar for app A would risk changing the menu bar to something non app A.

That "menu autoraise" behavior is incompatible with focus follows mouse, at least for me. I think other comments have mentioned this issue, too.

11:25 AM, April 26, 2008  
Blogger spuddybuddy said...

Real Programmers don't use the mouse to switch between windows, they create three keyboard shortcuts, e.g.

F2 focus/cycle among emacs windows
F3 focus/cycle among browser windows
F4 pause/unpause media player

this is more-or-less how i have fvwm2 set up at work. for doing things like this, nothing i have found for the mac comes close to fvwm2. then again, i do 90% of my programming on linux, so i haven't invested nearly as much effort as you have on the mac side of things.

1:35 PM, April 26, 2008  
Blogger Christopher J. Bottaro said...

I read the entire post.

I'm also a recent Linux convert (9 years of focus-follows-mouse), and your post is like a magic mirror into my brain.

I'm trying so hard to be a Mac fanboi, but I'm starting to think that I might go back to Linux if KDE4 pans out well... :(

I have to say, I do like TextMate (previously coming from Kate and previous to that, vim).

Great post, even though it's a little disconcerting.

1:47 PM, April 26, 2008  
Blogger Eugueny Kontsevoy said...

I wonder what flavor of Linux you've been using: historically fonts have always been the biggest deterrent for me to stay away from Linuses, but the latest crop of distros render simply beautiful fonts.

I have a mac too, but fonts are one of the reasons I made Linux my "primary desktop", I wrote a little about it here.

And finally, allow me to post a screenshot of my desktop, this is Ubuntu 8.04. I hope you'll like the fonts, Steve.

Keep up the excellent blog.

8:10 PM, April 26, 2008  
Anonymous Anonymous said...

>You're a glutton for punishment, I tell ya.

Are you kidding? We live for these articles!

Also kudos for the C++ FQA-link...

6:06 AM, April 27, 2008  
Blogger Roland Dobbins said...

CTVD development has been dead for years, unfortunately. It worked great on PPC, and it gave sloppy focus support (though not middle-button paste, worse luck). I finally gave up and switched to YouControl Desktop, which unfortunately lacks the sloppy focus feature.

6:13 AM, April 27, 2008  
Blogger Michael said...

I doubt that Apple will every implement focus-follows-mouse. Not only is it just a matter of preference, but more importantly the majority of users out there would be confused by it. If there mouse is on top of the wrong window, then when they type something it won't behave how they expected it to.

8:20 AM, April 27, 2008  
Blogger Singletoned said...

Having read the article yesterday, I noticed last night that I've been using 'scroll follows mouse' for ages without thinking about it.

If you put the mouse over a background app and scoll, the app under the mouse scolls even if it isn't the foreground app.

11:08 PM, April 27, 2008  
Blogger Patrik said...

On Classic Mac OS, there was an extension that implemented sloppy focus-follows-mouse. I don't remember the name, but I seem to remember that it implemented it by switching the application with the mouse, but locked the Z-order of the windows. That should work for any application - the application just draws to the window, and windowserver takes care of drawing the windows to the screen.

I think that it may be possible to do this with a simple NSUIElement app, but if that fails. there are two more options: APE, which indeed does work on Leopard if you have the 2.5 beta (at ) and SIMBL (at )

12:47 AM, April 28, 2008  
Blogger Brian said...

I'm late to this party, but I did write up my own blow-by-blow guide of how a Unix/Windows user can set up Leopard (10.5.2 fresh install) for maximum happiness (with macports programming tools included). I switched to OS X about 8 months ago and haven't looked back.

12:22 PM, April 28, 2008  
Blogger Andrew Harbick said...

CodeTek virtual desktop does what you're looking for (i.e. "mandarin orange" and not "rotten durian or buffalo carcass") I suffered your pain back in 2004 and bought and happily used CTVD for exactly the same reason. The problem though is that CTVD hasn't seen a new release since it broke with Tiger :(

That said it's was a proof by existence that it's possible.

3:01 PM, April 28, 2008  
Blogger Matt said...

This comment has been removed by the author.

5:46 PM, April 28, 2008  
Blogger Matt said...

This comment has been removed by the author.

5:47 PM, April 28, 2008  
Blogger Matt said...

This comment has been removed by the author.

5:48 PM, April 28, 2008  
Blogger oillio said...

Nice rant. I like Mac stuff because it is better than anything else. But it's not perfect. And you hit the nail on the head concerning the serious deficiencies in it's community.

On a technical note:
I don't have any experience writing Mac apps but couldn't you just fake the target window being in the background? Allow the target window to be brought forward and paint the relevant windows over it, or make the relevant bits transparent.
It's hacky and would require a lot more work. And be more easy to break. And would do funny things with some programs (like Photoshop).

8:12 PM, April 28, 2008  
Blogger Jesse said...

You should check out KDE4 sometime in the near future. I'm experimenting with it in Fedora 9 (pre-release), and the font rendering is really crisp. (I did recompile freetype2 with the byte-code interpreter.) I have Monaco, Consolas, Inconsolata, etc installed and they all look great. The fonts of my emacs session look better in KDE4 than they do in Gnome 2.22. Comparing window captures from each environment of the same chunk of code, same font (Monaco 9pt), same font dpi setting (120) reveals a difference in the font height, KDE4 rendering giving a bit more, which makes it look more natural and readable to my eyes.

-- a long time Gnome user who is stuck in KDE now because of the font rendering

11:17 PM, April 28, 2008  
Blogger George Reilly said...

I find it ironic that SteveY is complaining about his middle-aged eyes needing larger fonts, yet in Mac Firefox 3, the font size (Georgia @ 16px) is tiny.

12:31 AM, April 29, 2008  
Blogger dmh2000 said...

>I'm getting old...40

sorry, but 40 isn't old. you are in your prime. wait until you have to buy a magnifying glass to read the small print in books.

8:21 AM, April 29, 2008  
Blogger Will said...

I'm a programmer who uses Windows exclusively and have never understood why anyone would want focus-follows-mouse because I'd only ever seen it with auto-raise before. So read this article and decided I had to try TweakUI with no auto-raise because that sounds incredibly useful.

Unfortunately it does _not_ work properly for me. Many windows work fine, but some types of windows apparently will always get raised up when the mouse is on them, despite auto-raise definitely being checked off. Tragically, Visual Studio is this sort of window, and since I run Visual Studio stretched across both monitors taking up all available screen space, that means any time my mouse goes off of anything, it pops to the front and covers up every other window. So much for my dream of being able to have a Firefox window on top of Visual Studio and still be able to type code.

Anyone know anything else to try in Windows to get this non-raising behavior to work correctly?

3:16 AM, April 30, 2008  
Blogger Alan said...

I don't know if it's come up yet, but I noticed that the trackball/scrollball on the mighty mouse uses focus-follows-mouse. Whichever window the pointer is in gets scrolled when you roll the wheel, without affecting the menu bar.

6:58 AM, May 01, 2008  
Blogger Pete Mao said...

The "user will get confused" argument is null and void. FFM (I prefer the fvwm term "focus on enter") can be an option that I could activate, so the old apple users never need to know about it.

Philosophically, FFM assumes that the user knows how to use a mouse and places the pointer with intent. Apple's normal interface assumes that the users are all idiots (or maybe just twitchy).

11:09 PM, May 02, 2008  
Blogger Robert Fisher said...

I wouldn’t mind if Apple added focus follows mouse. I’d probably use it if they did.

But like so many other possible preferences, I don’t think it is that big a deal. Yeah, if you really like it, you get the bong bong bong of it missing, and that’s annoying.

I feel much the same way about many of the default GUIs you get by default with Linux these days. Bong bong bong: This feels like an unholy Mac/Microsoft/NeXT love-child rather than a well-designed GUI. The great thing about Linux, though, is that it has a gajillion options, and if it doesn’t have the one I want, I’m able to fix that.

So, when I want maximum flexibility, I’ll go with Linux. (OK, I’m personally more inclined to go with FreeBSD these days, but the point is mostly the same.) I choose Mac for other reasons. One of those, is being judicious about how many preferences they bother implementing.

12:34 AM, May 03, 2008  
Blogger Mietek said...

Please post the source code for your hack.

8:21 AM, May 05, 2008  
Blogger gpshead said...

Like code? Take a look at for some Mac OS X focus follows mouse fun.

12:16 PM, May 10, 2008  
Blogger Chris said...

Hi Steve, very interesting article, as a developer myself, I feel your pain. I love my Mac (Mac user for a year now), but the UI focus doesn't work as I would like it. The autofocus, which works fine for X11 apps in Leopard, it the one thing I miss the most.

3:48 AM, May 11, 2008  
Blogger Russell Wallace said...

I don't personally use overlapping windows, but would it help to use an extra monitor? Then you could put the window you don't want at the front, into the extra monitor, and type into it without it getting in the way of your other windows.

5:22 PM, May 20, 2008  
Blogger masak said...

Chiming in with Jeremiah, I sometimes really miss automatic copying of text, like in X. If anyone knows of a way to get Mac OS X to do this, I'd be forever grateful.

5:11 AM, May 22, 2008  
Blogger Alexandros said...

This is not a question of switching between windows or having to save a single mouse click.

Right now as I type this message, I'm watching 'memento' in VLC viewer. Because of mac's focusing behaviour, I have to put my firefox window on top of the VLC window and watch just half a movie.

If I was doing the same task in linux, I would have my firefox window BELOW my VLC window and just typing without looking.

I just have a feeling that this behaviour should not be this difficult to implement. It should just be a quick way of giving a window a certain Z-depth but not necessarily giving its application the focus.

In unix there are no crazy programming constructs, it's just handled by the window manager.

It's happened to me many times when I use photoshop. My palettes will get lost beneath my finder windows whereas my working photo will be at the top in focus.

Let's not try to reinvent the wheel, it should be like a very simple thing. Query the window beneath the mouse (On mouse over anyone?). Raise it to Z-depth= 10000 until it almost cracks the LCD monitor. don't give its application any focus. I swear to god I had experienced this in OSX before. It must've been linux and I must've been stoned.

6:11 AM, May 27, 2008  
Blogger The Cypher said...

Quartz composer:

It seems to me that this is the level at which we should attack. The Quartz composer stores the location and Z-index of all the windows of the screen and their content (represented as a bitmap).

If we could get quartz composer to raise a window when the mouse hovers over it (without giving its application focus) we could have the autofocus functionality we've always wished for!

This is entirely possible, as I mentioned earlier, I was watching VLC viewer. On VLC there is an option to 'float on top'. Floating on top is equivalent to raising a window but not giving its application focus, non?+

1:35 AM, May 29, 2008  
Blogger yogh said...

I've heard the rumors about 10.6 Snow Leopard being all Cocoa. While I'm not hopeful, perhaps this would mean that stuff like all those Carbon APIs you were digging through will be ported to Cocoa. Then you could have all the RubyCocoa fun you wanted!

Anyway, here's to dreaming.

7:49 PM, June 06, 2008  
Blogger John said...

Stevey, your programming chops are way better than mine, so all I can contribute is encouragement to get this working. You would be a god in my eyes.

As for the point that Mac is supposed to assume users are idiots, I agree. That's cool. It should be this way. My parents constantly screwed up their Windows machine. I thought of giving them Ubuntu, but its power would only cause more problems. They've been happily and successfully using Mac since last Christmas.

But FFM could be a hidden feature. It could even be turned off at each startup. Then, the only people who would have it persistently would be people who at least know how to make their own startup item.

12:57 AM, June 09, 2008  
Blogger Denton Gentry said...

> Steve Yegge wrote:
> A related observation is that you can scroll-wheel scroll background applications.

Additionally when iTunes is minimized (by clicking the green window button) and running in the background, you can click on its pause/play and skip buttons without bringing its window to the foreground. Clicking elsewhere in the window does bring iTunes to the foreground.

Presumably this means that iTunes itself contains code to specially handle clicks whilst not the foreground application, and may not help when trying to extend the behavior to be system-wide.

10:19 AM, July 01, 2008  
Blogger Aaron said...

This comment has been removed by the author.

9:13 PM, July 06, 2008  
Blogger Aaron said...

Surely it must be a relatively straightforward issue in Mac OS to implement the sort of 'focus-follows-mouse' that doesn't require you to click once to get focus, and then click a second time on whatever button/link you want in the app you've just got focus on - i.e. to get focus and click on the thing you want in ONE click? That's a third sort of 'focus-follows-mouse' that is much less discussed (probably because both Windows and Linux have it), but for met at least it's the most aggravating in Mac OS. Come on, the web browser is there open on my desktop, and I have to click twice to open the link? How can that be an usability advantage under anyone's idea of a good OS environment?

The reason I say it must be easy to fix is that VMware Fusion does it. Windows' windows are displayed in Unity Mode and the focus works like it does natively in Windows - you click on the app and the button/link you want in one go and it gets focus. If you have set the Taskbar to be displayed in Unity, you can just click the Start menu button anytime - you don't have to give Fusion focus, and then click it. You can click it anytime, just once, irrespective of what Mac app currently has focus. I assume Parallels manages it as well, though I don't use Parallels.

So someone - please write a quick hack to provide this with ALL Mac OS windows, not just Fusion/Parallels.

9:18 PM, July 06, 2008  
Blogger Robert Fisher said...

“How can that be an usability advantage under anyone's idea of a good OS environment?”

If the window isn’t frontmost, then the user may not be able to see what it is they’re clicking. That first click may be a mistake. (The user meant to click on something near the edge of the window in front instead.) Or perhaps the user means to bring that window to the top, but—because they can’t see the entire window—doesn’t realize exactly where in the window they are clicking.

The usability idea here is that when the window isn’t frontmost, the system is less sure about the user’s intention. So, the system shouldn’t act in this case other than to bring the window forward and focus it.

Please note, I’m not saying you’re wrong for preferring it be different. I’m saying that—whether you agree with it or not—there is good reason that this is the default behavior.

(I actually prefer this behavior and have been annoyed by systems that make it difficult for me to choose it.)

4:24 AM, July 07, 2008  
Blogger David said...

Rober Fisher: "If the window isn’t frontmost, then the user may not be able to see what it is they’re clicking. That first click may be a mistake. (The user meant to click on something near the edge of the window in front instead.) Or perhaps the user means to bring that window to the top, but—because they can’t see the entire window—doesn’t realize exactly where in the window they are clicking."

But you can see what you are clicking: it is right there under the mouse. I do understand that click-to-focus might be an OK default, but that you are prevented from interacting with the visible bits of large areas of the screen seems goofy. Everything that isn't in the active window is just a visual menu of some of the alternate jobs of the window manager.

It does not seem at all like bad UI design to give a user the option of interacting with things visible on their screen. If you think of papers on a meatspace desktop, you don't need to pick one up to copy the data off of it,, and you don't need to put the paper on top of the desk to write on it.

I don't object to the default click to focus, I object to the impossibility of focus follows mouse.

The awkward use cases with FFM are where you can change focus a couple ways: move the mouse to focus on window 1, then use Cmd-Tab on the keyboard to focus window 2. Should the focus follow the mouse back to window 1? Or should window 2 keep focus until the mouse jiggles?

7:01 PM, July 10, 2008  
Blogger Robert Fisher said...

“But you can see what you are clicking: it is right there under the mouse.”

Not when it’s only a few pixel peaking out from behind four or more other windows. In fact, when this happens, I usually don’t mean to be clicking on that window at all, but on something near the edge of the frontmost window.

It may seem goofy to you, but I’ve been burned way too many times by systems that don’t act that way and saved too many times by ones that do.

8:33 PM, July 10, 2008  
Blogger Aaron said...

"Not when it’s only a few pixel peaking out from behind four or more other windows." The only times when it's a 'few pixels poking out' is when it's the very edge of an obscured window - in which case you're not going to click on anything active anyway; it's window decoration. So I don't see the issue here.

Also, note that OS X is *inconsistent* when it comes to click through. In Safari, for example, you click-through to menu items and the navigation buttons (forward/backward), but not to hyperlinks. That's just dumb. And by the way, if you object to click-through at the *edge* of the window, note that in OS X you are *more* likely to find these objects you can click-through to at the edge (menu buttons, etc) but you are *less* likely to expect it (since OS X has click-through turned off for most stuff). Therefore, I would expect you to find OS X worse and Windows a better designed OS, and less likely to annoy you, since it is more predictable and more consistent.

I also object to not having the *option* of click-through and turning click-to-focus off. But I did find one situation in which click-to-focus is useful. If you want to copy from a window where the text you're wanting to copy is already highlighted/selected, clicking through to the window on the main body of the window (where the text is) in OS X does not remove the highlight, so you can click then CTRL-C to copy and go to your window where you want to paste. In Windows you have to re-highlight the text because click-through will remove the selection, or be careful that you don't click on the text - although if it's the bulk of the text in the window that can be tricky.

7:19 AM, July 13, 2008  
Blogger Robert Fisher said...

The only times when it's a 'few pixels poking out' is when it's the very edge of an obscured window

This is not true. Perhaps you should consider this matter further.

7:40 PM, July 13, 2008  
Blogger Robin said...

Will: True X-Mouse works better than TweakUI for autofocus on Windows. It doesn't solve all the quirks with Visual Studio, but I find it quite usable. See:

7:21 AM, July 27, 2008  
Anonymous Anonymous said...

Wow. I no longer feel alone; I am another re-treaded linux user now working on Macs. I love Macs, but do so miss focus-follows-mouse just like Steve and others describe. And I have had the same experience that Mac and PC users just do not get why this matters so much. Even some other linux/unix users don't seem to be bothered by it, but they must not program much or use lots of windows at any one time. Focus-follows-mouse will never be implemented correctly in Mac OS X until Apple decides to put the menu bar back on the app window where it belongs IMHO instead of divorced from its app at the top of the desktop screen. (How many times have I printed the wrong window because I did not first click on the one I wanted to print?)

Two other gripes I have with Mac OS X:

1) I also sorely miss the linux ability to be able to *lower* a window by pressing a function button or clicking. When you have a bunch of windows open and one or more are totally obscured, cycling through the stack by lowering the topmost is way more efficient than using Expose and hunting amongst 30 teeny icons for the one window you need, especially when many of them are indistinguishable terminal or xterm windows.

2) A gripe related to the focus problem happens often. I am not sure it even has a name, but the most common example is when I am working away with say, 5 Safari windows open and bring up my mail to read. Someone has sent me a url to an interesting website; I click on it, and, nicely, a new Safari window appears and I soak up as much as I want. Now, I want to return to my mail, so I close the latest Safari window, the only thing obscuring my mail tool. Alas, this action causes the OS to believe that I am now using Safari and instead of my action allowing me to reveal my mail tool, it raises the next Safari window to the top of the stack. I just want to go back to reading mail - the only way to do this is to click on the mail tool somewhere.

If anyone knows of fixes for these issues, please share! And my sympathetic vibes and encouragement to all who are working on solving the focus issue, as hopeless as it seems to be.


1:22 PM, July 31, 2008  
Blogger David said...

After using my Mac a little more, I noticed that the Mac is inconsistent about its no focus-follows-mouse policy:

1) dragging text to another window. You can paste into background applications without raising them. I was hating the copy-raise-paste-raise cycle until I learned this.

2) menu-bar buttons (close, min,max) -- Those unfocused little grey buttons glow when you hover over them.

These two examples of focus-follows-mouse behavior are samples of what us FFM people are enamored of: you can interact with what you see on your screen. Letting users minimize or paste, but not do the other visible actions seems inconsistent.

I do understand that FFM would make the top-bar menu hard to use as you scrolled over the intermediate windows, and that FFM without window borders doesn't give you a clear mechanism to signal 'raise', but still, it would be nice to have the dang option to interact more with what you show on the screen.

Scrolling and pasting from a background window is hard habit to give up.

12:00 PM, August 18, 2008  
Blogger blahedo said...

Whew, there's a lot here. I'm a longtime Mac user (since 1990) and Unix/X/fvwm user (since 1994), though until OS X I had to interact with them in very different ways, and from the time I started being a power-user in *nix environments to the time Mac became a *nix environment (sort of), my Macs were pretty much just for play. There was a whole list of features I missed when I started moving to Macs as "real work" machines:

*Control/Caps Lock swap

*Esc and Backspace in the Sun keyboard locations (where Mac/PC has backquote and backslash respectively—closer to the home row)

*keyboard-based mouse-pointer movement

*keyboard-based raising and lowering of windows

*focus follows mouse (which is really focus follows mouse-pointer, which is glorious in combination with the previous two)

Apple eventually gave me my Control key, and I've found KeyRemap4Macbook (not just for MacBooks) for the other remappings. No dice on the keyboard controls, but until recently I'd used CodeTek's VirtualDesktop for the FFM. It's certainly a proof that it's possible, and it did it right—the focused window need not come to the top, but it has first-class focus and a menubar. There is a tiny delay (iirc configurable) between the pointer entering the window and focus shifting, which resolves the menubar issue. The only frustrating thing is that the true FFM behaviour only worked with Cocoa apps: there was no way to give Carbon windows focus while they were still in the middle of the pile. Faced with a bad choice and a worse one, CTVD made FFM do the durian thing in Carbon windows, which was annoying, but mostly it worked great.

If you do play with this some more, please please please post it! I've just upgraded to Leopard, and as noted above CTVD appears to have abandoned their codebase, presumably driven out by the far-inferior Spaces—but that's a separate rant. Point being, I've lost FFM all over again and I'm not happy about it. :(

10:05 PM, August 28, 2008  
Anonymous Anonymous said...

Thanks! That worked perfectly. I really missed GrowlMail and I'm glad to have it back.

1:49 AM, September 08, 2008  
Anonymous Anonymous said...

defaults write FocusFollowsMouse -string YES

1:33 AM, September 18, 2008  
Blogger Doug said...

Steve, as an old, old X user and sysadmin (think twm as the primary window manager and it was an upgrade!) I loved the blog. I actually had tears in my eyes from laughing so hard. Been there ... So true, so true.
Just recently bought a Mac mini for the wife and I can retire the Windows machine. Found your site because I wanted to change to focus follows mouse and was googling around. You're right, the screen is beautiful but since I cant get past the BONG, I'll probably stick with my KDE. You didn't even go into modifying window behavior like being able to bottom the top window with a click but most of the posters just didn't get it.
Just had to let you know how much I appreciated the blog.

3:41 AM, October 12, 2008  
Blogger Sonny said...


I'm investigating AXUIElementPostKeyboardEvent for an entirely different reason, and from a much lower level of expertise. Still, your post led me in a lot of useful directions.

The open source application ClonedKeys implements AXUIElementPostKeyboardEvent in a way that successfully passes modifier keys.

In one function call, it seems modifier keys are passed into the seemingly useless (and misdocumented?) third argument:

err = AXUIElementPostKeyboardEvent((*index).application, (CGCharCode)0, CKModifiers[k], true);

(This is line 180 of CloneKeys.cp, viewable at

I have tested this by linking the software to and Firefox and entering vi commands into the Terminal from Firefox. Aware from comments here that might just "play right," I also tested a World of Warcraft Macro that behaved differently upon the addition of the ctrl modifier key, both as a background window on screen and as a foreground and background window from another "Space."

If you're still interested in tackling the problem, hopefully that code can be helpful.

6:44 AM, October 24, 2008  
Blogger Sonny said...

Update: Having added two features to the ClonedKeys software myself, I can assure you that we are successfully passing modifier keys to background applications using AXUIElementPostKeyboardEvent. I strongly encourage you to check out our code.

7:46 PM, October 29, 2008  
Blogger -L said...

Steve, as a long time Mac user I think focus follows mouse sounds quite attractive and would very much like to try it, if you would be willing to provide your code. I quite often find myself juggling windows in a way which I think might be mitigated by such a mechinism.

If nothing else, I enjoyed reading your post.

8:04 PM, November 17, 2008  
Blogger Jason said...

Wow, this is by far the best and most comprehensive summary of the focus-follows-mouse dilemma that I've read. Thanks for taking the time to do all of this research and then share your findings!

11:45 PM, December 09, 2008  
Blogger FaNRH9hvH7YK said...

CodeTek did provide true focus-follows-mouse (i.e., without auto-raise) for Cocoa apps; Carbon apps did auto-raise. For my money, it was worth forty bucks for this feature alone. Sadly, though, it seems to have vaporized, its website notwithstanding.

Sadly, I think that this is one of those features that you have to have grown up with to really understand. For me, it's not about _how_ to focus (i.e., moving the mouse v. clicking v. keyboard shortcuts), nor about speed or convenience of focussing -- it's about how focussing fundamentally _works_. I'm used to using the mouse to focus in this way, but really I'd be equally happy with a keyboard shortcut for focus-without-raise. Something like Command-Ctrl-Tab to switch focus like Command-Tab but not raise would be awesome.

It would be lovely if something came of all this, but I'm not holding my breath. Unless someone makes a breakthrough on this issue, I'm un-switching (back to unix) the next time I need a new machine.

12:11 AM, December 18, 2008  
Blogger Nathan said...

I think the reason you can read the fonts is the higher resolution; the dots-per-inch. Higher resolution fonts are bigger (so, your eight might really be a normal 12) and, yes, look much better. If the resolution is the only reason you're there and you want real, un-kluged focus-follows mouse, I'd recommend Linux, where you can just manually put it up (without even having to touch a file ending in "rc").

7:28 PM, January 15, 2009  
Anonymous Anonymous said...

I feel your pain. I guess I'll stick with Windows. I couldn't use a Mac as my main machine for this reason.

I frequently use focus-follows-mouse to enter data into one application while referencing data from another application in the foreground. This is not possible without some way to switch focus without raising the app.

Your wish to the Mac Fairy could be phrased differently. Wouldn't it be sufficient for OS X developers to actually switch focus to the app under the mouse without raising it to the front? That is, go ahead and change the menu bar, but don't change the z-order of the windows.

11:31 AM, February 12, 2009  
Anonymous Anonymous said...

To Jason -- this idea is available in some desktop managers (one, at least) for the Mac, though it is tricky to implement. In the naive version, it would be well-nigh impossible to get to the menu-bar of a particular application if the cursor had to cross through other application windows on the way - the menu bar would belong to whatever application the cursor last crossed. The answer is to do what you suggest AND glue the menu-bars back on the individual application windows where they belong! This is one thing that Apple has gotten altogether wrong IMHO because it makes the window managing less flexible. The one window manager that does allow focus-follows mouse without also raising a window to make it active uses a built-in delay for deciding whether to switch the menu-bar or not. This kind of works, and also can be frustrating, both in waiting for the delay to kick in when it's not needed and also when you inadvertently dilly-dally a little when you should be rushing to the menu-bar.

2:08 PM, February 12, 2009  
Blogger Beast said...

Stevey, I feel your pain.

I have had my iMac for two years or so, and I still haven't adjusted from FreeBSD + Gnome + focus follows mouse. Although it was a bitch to find the option to do focus follows mouse in Gnome.

What's also annoying is that you often have to click twice. Once to get focus into the app window. Then again to get focus in a subframe or pane or whatever the jargon is. e.g. One click for focus. Another click to select the message you were reading, even if that's what you were doing before you sent focus elsewhere.

Next question: what about keyboard shortcuts? Ironically, it's the only feature of the Windows GUI I like.

12:32 PM, February 15, 2009  
Blogger Mo said...


Mac OS X has keyboard shortcuts for everything.

Pretty much every Cocoa app supports Emacs/readline-style shortcuts in text editing fields (e.g., Ctrl+A, Ctrl+E, etc.)

12:35 PM, February 15, 2009  
Blogger Beast said...


I know what you mean, but that's not what I meant :)

In windows, when you look at the taskbar for the app, then File has an underlined "F". Pressing ALT+F makes this menu drop down. And you can see either shortcuts for other commands, or a way to navigate to all options or submenus via a keystroke or two. No mouse required.

I know of no way to do this in Mac OS X.

9:00 PM, February 15, 2009  
Blogger Mo said...


While there isn't a "show accelerators when you press a key" thing as on Windows (I wish there was, though), and you can't pop down a specific menu, you can access the menu bar and select menu items without using the mouse. Have a look at System Preferences → Keyboard & Mouse → Keyboard Shortcuts. You'll need to turn it on, I think, but the default shortcut for highlighting the menu bar is Ctrl+F2.

11:59 PM, February 16, 2009  
Blogger Beast said...

@Mo: Ctrl+F2 works just fine!

It's good enough for me.

Thanks very much.

10:40 AM, February 17, 2009  
Blogger parity error said...

I'd be happy to get FFM within Firefox. Using the up/down keys gets you {doh..} up/down the browser screen UNLESS you are focused not in the body but up at the address bar.

THEN it takes the cursor key input and flies along the tab bar, depositing you on some totally different page. That's why it's a curser key!

If FFM worked within FF, I'd be really happy.

4:01 PM, February 19, 2009  
Blogger Chien said...

Apologies if this has been suggested before:

To make focus-follows-mouse not activate the wrong menu in Mac OS X, one solution is to assign a hot key (ctrl, fn, caps-lock, command, option). When the hot key is either held down, or toggled, the global menu bar freezes to the application currently under focus, allowing the cursor to safely traverse over other windows. One might call this the "Moses mode." When released, or toggled again, the menu bar is allowed to reflect whichever application is under the mouse.

6:46 PM, July 30, 2009  
Blogger David said...

In some ways, the focus-follows-mouse really can be an accessibility issue. Having fought carpel-tunnel syndrome for years, I have found that if I can minimize mouse clicking when switching it helps. FFM is much easier on my hands than using than the Mac click to focus ORE the cmd+tab option approach.

So, as much as I like my mac, FFM is essential for most of my work and I have to mostly use a linux system. I would switch in an instant to a Mac if it had a workable FFM option. I really wish that FFM (even if imperfect) were a standard option in the finder.

7:02 AM, September 24, 2009  
Blogger Mikey said...

Try using the GIMP on OS X without the focus-follows-mouse functionality. Essentially the experience boils down to having to double click on each window in order to perform the desired action (like selecting the bucket tool when the layers window is open for example).

I guess if your used to the focus-follows-mouse behaviour, command-tab never cuts it. There is a subtle mental difference between them, namely, being able to access the window you are looking at with the mouse rather than "remembering" which window you used last. That being said, this applies to myself who uses a dual-monitor setup with usually < 3 apps per a workspace. I imagine that if a laptop display is being used with 10 applications open usually only 1 would be displayed at a time, and command-tab is optimal.

5:55 PM, November 01, 2009  
Blogger KP said...

Wow - I came here hoping for insightful debate about an important problem for OS X users/developers, and what do I find?

"I'm tempted to shut off comments so I don't have to hear any more of this drivel. This is the worst blog commentary I've ever had, and it doesn't speak well of the Mac community."

A blogger pissing all over his audience.

First and last time I visit this shit-hole.

1:46 PM, January 15, 2010  
Blogger Greg A. said...

Awesome, Awesome, Awesome, article!


I could not have said it better myself!

I hadn't even really formalized the difference between autofocus and autoraise in my own thinking before -- to me the very idea of autoraise is so stupid and broken and undesirable that I couldn't even conceive of anyone wanting it in the first place.
When I first complained about the lack of autofocus on OS X and someone pointed me to something that implemented autoraise instead I was to traumatized after trying it that I nearly erased the whole memory from my mind! What a horrible mis-understanding of the reasons for autofocus!

I didn't read many/any of the other comments, except one very near the end, and that one I kinda agree with.

I.e. I don't really care about whether the menu bar switches to the active app or not, but if that would help make things easier under the hood, then that's what should happen! (I really don't like the single menu bar and would prefer one on every window too, but I gave up on that argument back in the 80's)

Someone else worried that keyboard-focus-follows-mouse means one has to be a very careful mouser, and indeed that's exactly what it means! That's what all of us really do want -- and we've learned to be very careful with our mouses because we've always had to be very careful with them.

Indeed having the menu bar switch when the focus changes due to mouse cursor movement to a "background" window would be yet another good visual indication of where keyboard input is headed.

Now that my laptop and my desktop are both OS X I'm even more concerned about lack of autofocus because I'm using one eSpace workspace for X11 with its own window manager (ctwm), and jumping back and forth sometimes causes me to nearly make dangerous mistakes if I forget to click on what I'm looking at.

I'm also really desperate to find a shortcut that'll send a window to the back -- even if it doesn't also switch apps. Indeed most often I just want to send the top window of many from the same app to the back to find the next top-most obscured window.

1:47 PM, January 15, 2010  
Blogger Dan Harkless said...

The "my ideal font point size appears to be (age/2)" thing was amusing, but what computer were using as a 12-year-old in 1980 that you preferred to use 6-pt. fonts on?

Unless your Dad worked at Xerox PARC and let you play around on the systems or something, I don't see how that's possible.

5:48 PM, March 23, 2010  
Blogger Trixter AKA Bret McDanel said...

I was wondering if you would make available the code that you have done so far. That way others can at least get some functionality or learn from it.

I am somewhat curious if the last 2 years fared better than the previous 6 for the carbon bug.

This is a lesser problem for me now that I have it working in terminal and that is where I switch rapidly and all that. It would still be nice because I frequently find myself typing into the wrong window :)


10:06 AM, May 03, 2010  
Blogger richf said...

I looked around a bit, and indeed it appears that most addons advertising FFM are really just implementing auto-raise. However, I did find one (CodeTek VirtualDesktop Pro) that explicitly states: "Focus Follows Mouse can focus a window without raising the window". Haven't tried it yet, may try their demo.

11:57 AM, July 15, 2010  
Blogger captain said...

Thanks for all the great info about mouse following focus on OSX. I guess I've learned to deal with the way Apple wants us to do it though... except for one HUGE thing - OSX/Apps STEAL FOCUS from me in the middle of my typing!

I wonder if anyone here has found a way to keep OSX from CHANGING FOCUS? e.g.: keep those damn popups in the background, or at least not the focus of the rant I'm right in the middle of and on a roll! ;-)

I've googled as best I can and come up dry, except for a hit on the same thing mentioned way above ( ) and that appears to require a lot of work for an uncertain outcome.

I just want popups and dialogs to stay bouncing in the dock (or something, ANYTHING else) and not steal focus from what I'm working on.


2:47 PM, August 16, 2010  
Blogger 5thDimension said...

thanks for the blog, I enjoyed it.
Apple's pretty good at reading their bug reports, I've found. you might try it.

1:37 AM, September 15, 2010  
Blogger NC Firewalls said...

Nice thread. I am new to Mac OS and, having used X11 for over 20 years, the loss of FFM was tough. However, I found iTerm, which supports FFM (and X11 copy/paste behaviour), so all is well. However, I have noticed something interesting: regardless of which Mac OS app has focus, all the other apps still respond to the mouse's scroll wheel, even though they do not have focus. I wonder if there's anything in that behaviour that is revealing with regard to FFM. Thanks again for the good thread. Useful

9:06 AM, November 05, 2010  
Blogger necro351 said...

I use foucs-follows mouse at work with my Ubuntu workstation, and at home I don't. I wish I could though. I have learned a long time ago however (I've been using Macs off-and-on since OS X 10.1) that Apple designs their OS for their latest laptops, and would prefer their customers buy the new experience, rather than take the time to support an ever increasing list of systems. This philosophy penetrates every aspect of their system. Apple says to tinkerers: keep out, we don't want you here. This is in fact in line with their entire philosophy of controlling the user experience end-to-end, or 'design' as Jobs likes to call it. I don't know if its _just_ focus-follows-mouse that annoys you, or a million other things all rooted in the same problem as is my case. Even if you find a hack that works, they will not let you know when they deprecate/modify their APIs, or just retire an entire architecture (as they've done in the past) so your best bet is to just do it their way when you are using a Mac, and not use a Mac when you don't have to. Sorry, this post was quite cynical, oh well.

8:54 AM, November 24, 2010  
Blogger Curly said...

Enjoyed the rant, thanks :)

4:33 AM, December 21, 2010  
Blogger Jeff Kaufman said...

Somehow does the right thing here. It is able to get keyboard events, even modified ones, when the mouse is over it even if it's not focused. So maybe a true focus follows mouse would be possible using whatever it is that terminal does?

More details:

10:43 AM, April 06, 2011  

Post a Comment

<< Home