Support focus follows mouse (sloppy focus) with the global menu bar

Bug #774642 reported by Tim Allen on 2011-05-01
This bug report is a duplicate of:  Bug #674138: "Global" appmenu breaks sloppy focus. Edit Remove
34
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Unity
New
Undecided
Unassigned

Bug Description

Although I haven't been following Unity's development, I'm sure the fundamental incompatibility of focus-follows-mouse and a global menu bar has been much discussed. However, rather than just complaining, I have a suggestion.

Traditionally in focus-follows-mouse environments, every time the mouse moves the window-manager switches keyboard-focus to the window underneath the mouse-pointer. On a system with a global menu-bar, if the user wants to use a menu-option related to the current window, she has to move the mouse to the global menu-bar, potentially travelling over other windows which would cause them to be focussed and the global menu to display the new window's menus instead of the original window.

One workaround is to physically move the window in question up next to the menu-bar, but that requires a lot of tiresome shuffling. Another alternative is to forbid focus-follows-mouse altogether, which is regrettable but consistent. However, there's another option that I haven't yet seen suggested or implemented, which I think would work well.

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 while moving the mouse.

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.

If this suggestion has already been tried and discarded, I apologise for taking your time (although I'd still like to try it myself — I think even a somewhat clunky implementation would be better than the current state of affairs). If not, given that focus-follows-mouse is still available in Unity as an option in the official "System Settings" app, and that it has a long and popular history on the Linux/Unix desktop, I think it's worth giving my suggestion a try.

reanjr (reanjr) wrote :

I like this approach, but I think even more straight-forward (to my mind at least) would be to have a "global-menu delay" analogous to the "focus delay" as a separate setting. So if the focus delay were 0 and global menu delay were 1, moving the mouse to a new window would immediately focus it, but the global menu would not be replaced for another second.

Once the pointer is in the menu area, of course, the current global menu will be frozen.

This may also be better for accessibility in that someone might not be able to move the mouse smoothly to the global menu; with a setting like this, they can give themselves enough time to access the menu.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers