Settling the OS X focus-follows-mouse debate

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.)

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

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

defaults write com.apple.Terminal FocusFollowsMouse -string YES

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.

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

http://search.cpan.org/~cnandor/Mac-Carbon-0.77/Carbon.pm

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!

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

I think InputManagers are only loaded for Cocoa apps.

The complete way to do runtime patching is APE (http://unsanity.com/haxies/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)

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.

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.

"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

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

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)...

http://iterm.sourceforge.net/

Emacs should run great in it too :).

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?

iTerm pretty much only exists because Terminal.app 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 Terminal.app. 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!

Terminal.app is by far my favorite GUI terminal emulator (top overall is screen), on other platforms I use xfce4-terminal.

> 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 (codingrelic.geekhold.com) to add line-height to the enclosing <div> in the posts section like so.

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

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.

"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.

HTH

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.

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.

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.

Steve,

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

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

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.

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 com.apple.Terminal 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...

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.

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...

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.

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 :)

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.)

Steve,

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.

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.

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.

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.

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.

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

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)

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.

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".

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

Steve,

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™.

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 :-(

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.

Windows doesn't have a decent media player!

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 http://valhenson.livejournal.com/11711.html ).

I thought maybe Terminal.app 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 ( http://blogs.msdn.com/oldnewthing/archive/2006/01/09/510781.aspx 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...

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.

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).

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.

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

Terminal.app is not an X11 app. Thanks for actually reading my comment.

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.)

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...)

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

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.

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).

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.

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.

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.

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).

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 http://amorya.uwcs.co.uk/testfocus.zip -- 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.

Amorya

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 http://amorya.uwcs.co.uk/testfocus.zip -- 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.

Amorya

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.

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.

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

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.

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.

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.

Kirk,

> 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.

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).

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.

http://www.codetek.com/ctvd/

Steve,
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.
e.g. http://the.taoofmac.com/space/blog/2007/09/16/2010

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

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.

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.

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.)

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

DEAR STEVEGOD, GIVE ME FOCUS FOLLOWS MOUSE!

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

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

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 :-)

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..

This comment has been removed by the author.

[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.

“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).

@Ryan,

"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.

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.

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.

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.

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.)

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.

@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?

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.

This comment has been removed by the author.

Shane:

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.

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.

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.

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"?

This comment has been removed by the author.

@ 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.

@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.

@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.

>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.

"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. (^_^)

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 http://www.neontology.com

Have you tried Zooom? http://coderage-software.com/

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.

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...)

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.)

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.

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.

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

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.

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.

@ 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)

Just a quick question on how many BONKS people get because of autofocus. I played a little bit with autofocus in Terminal.app. 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.

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?

> 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.

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.

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.

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.

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

Are you kidding? We live for these articles!

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

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.

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.

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.

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 http://www.unsanity.org/archives/2008_02.php ) and SIMBL (at http://www.culater.net/software/SIMBL/SIMBL.php )

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.

http://yocto.wordpress.com/2008/02/27/personal-installation-of-os-x-1052/

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.

This comment has been removed by the author.

This comment has been removed by the author.

This comment has been removed by the author.

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).

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

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.

>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.

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?

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.

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).

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.

Please post the source code for your hack.

Like code? Take a look at http://code.google.com/p/xmouse/ for some Mac OS X focus follows mouse fun.

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.

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.

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.

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.

Quartz composer: http://guides.macrumors.com/Quartz_Extreme

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?+

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.

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.

> 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.

This comment has been removed by the author.

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.

“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.)

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?

“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.

"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.

“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.

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: http://fy.chalmers.se/~appro/nt/TXMouse/

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.

mdg

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.

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. :(

defaults write com.apple.Terminal FocusFollowsMouse -string YES

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.

Steve,

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 http://code.google.com/p/clonedkeys/source/browse/trunk/CloneKeys.cp?r=3)

I have tested this by linking the software to Terminal.app and Firefox and entering vi commands into the Terminal from Firefox. Aware from comments here that Terminal.app 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.

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.

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.

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!

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.

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").

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.

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.

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. Mail.app. 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.

@Beast:

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.)

@Mo

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.

@Beast:

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.

@Mo: Ctrl+F2 works just fine!

It's good enough for me.

Thanks very much.

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.

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.

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.

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.

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.

Awesome, Awesome, Awesome, article!

Sigh.

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.

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.

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 :)

Thanks,

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.

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 ( http://unsanity.com/haxies/ape ) 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.

Thanks!

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

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

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.

Enjoyed the rant, thanks :)

Somehow terminal.app 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: http://sccs.swarthmore.edu/~cbr/news/2011-04-06.html