GNOME and the way forward

Posted Aug 18, 2005 18:03 UTC (Thu) by newren (subscriber, #5160) [Link]

Keyboard navigation can be made to work in a strict focus-follows-pointer by *moving* the pointer. I have done this in flwm and it seems to work very well. When shortcuts are used to move the focus the mouse is moved to the nearest point in the window, plus a few pixels.

Fair point and sounds like a fine criteria for you; we considered it but didn't really like the idea of warping the pointer around.

People really are thrown off if a focus-follows-pointer if at times the focus and pointer do not match. Do not do it.

I understand in general, but there's a number of caveats:

First, this just isn't possible due to application grabs of the mouse, windows that should not get focus at all, and windows that shouldn't be focused except in special circumstances (e.g. desktop windows that covers the entire screen or taskbars/panels).

Second, not all people are surprised by this (in fact, many focus-follows-mouse users are surprised if applications they launched don't get focused; yes there was a time when Metacity didn't focus new windows and lots of users, including those using focus follow mouse, who got surprised).

Third, it'd make clicks in the wrong place on the window list/taskbar really damaging as the user would then have to move the mouse a long ways to go and click where they really meant to on the taskbar. It's a tradeoff; and one where we picked allowing mouse navigation constraints (focus is under the mouse) to be temporarily suspended instead of warping the mouse.

Fourth, if users are so confused by the focus not being under the mouse, why then do most focus follows mouse users seem to prefer don't-defocus-on-window-exit-unless-entering-a-new-window? It matters in more ways than you probably notice at first; in particular think about this hairy condition for users who use keynav to move a window a few workspaces away: if the pointer wasn't on any window in the first workspace but after switching a workspace it is on a different window than being moved, what should happen? Should the window that the mouse is over get focus? That would likely result in the user moving that new window to a different workspace when they meant to move the original window more than one workspace. Should the WM then warp the mouse to the window that moved workspaces? Seems really weird that the user can interact with the window for a while but the warping of the mouse doesn't happen until then. (Personally, I treat this as a "user is using the keyboard to navigate instead of the mouse so mouse navigation invariants are temporarily suspended until the user starts using the mouse again"--seems to work great and gracefully handle the conflict between keynav and mousenav without warping the pointer; haven't had complaints with this method so far, other than the "don't focus new windows ever" thing which can be an added option)