Comment 13 for bug 674138

I would like to propose a different solution:

Observation: People going for the global menu-bar generally take advantage of Fitt's Law and shoot the pointer straight upward, rather than meandering about.

Observation: People using focus-follows-mouse are generally in one of two states, either interacting with a single window or moving the mouse to focus a new window - they never interact with windows as they move the pointer past them.

Idea: Use 'is the mouse moving' as a heuristic to determine whether to focus the window under the pointer.

For example, the window manager could store the pointer coördinates when it receives a mouse-move event, then have a periodic timer that fires (say, once per frame) and compares the then-current pointer position with the last stored position. Because people rarely interact with windows while they're moving the pointer past them, and because the timer (once per frame, or ~19ms) is so much shorter than human perception (100-250ms), it shouldn't cause anyone grief - the only noticable change should be that reaching for the menu bar Just Works.

If the once-per-frame counter doesn't achieve the desired effect, the usual batch of UI adjustments would be available: running the timer faster or slower than once a frame, checking whether the mouse-pointer has moved by less than a certain amount rather than an exact "not equals" comparison, etc.

Unlike MPT's suggestion in the wiki, this would not require creation of a separate focus state; unlike the suggestion in comment #11, there's no fixed timeout that aggravates the slow (with false-positives) or the fast (with false-negatives). A single frame's delay should be much, much faster than the time required to move your hand from your pointing device to the keyboard, even if you're using a trackpoint. ;)