GNOME Bugzilla – Bug 678169
make 'focus follows mouse' work
Last modified: 2012-10-11 14:39:10 UTC
It will never be perfect, because focus-follows-mouse is a somewhat broken concept, but we should acknowledge the fact that many of our users do use this. Particularly problematic for focus-follows-mouse: - Backdrop theming causes a lot of flickering as you mouse around - Crossing other windows on the way to the app menu One proposal that I have heard is to add a delay before we actually switch the focus. That should alleviate both issues, at the cost of forcing people to wait for the focus to arrive. If we make the delay too long that could be very annoying. A better approach may be to look at velocity and only switch focus if the pointer slows down sufficiently.
(In reply to comment #0) > [...] > - Crossing other windows on the way to the app menu > > One proposal that I have heard is to add a delay before we actually switch the > focus. That should alleviate both issues, at the cost of forcing people to wait > for the focus to arrive. I have a local patch that adds a delay to the app menu, e.g. while the focus is still switched immediately, the app menu is only updated after a small timeout. It works mostly fine in testing, making it possible to open the app menu without delaying the actual focus change. So far the only problem I've found is the following case: (1) Focus window (A) (2) Move over window (B) to open the app menu (focus moves to (B)) (3) Open the app menu for window (A) (4) Move pointer over window (B) => the app menu is not updated to (B) (as there is no focus change between (3) and (4)) Alternatively, we could change the semantics of the app menu to reflect the last raised app rather than the focus app (there should be no actual change in behavior for the default "click" focus mode as far as I can see)
why not attach it ?
Sure, will do in a bit (both approaches will need work though)
Created attachment 216863 [details] [review] panel: Delay app-menu changes when using focus-follows-mouse First option (with the issue noted in comment #1 still present)
Whats the next step here ?
to answer myself: discuss with designers at ux hackfest pre-guadec
Comment on attachment 216863 [details] [review] panel: Delay app-menu changes when using focus-follows-mouse Discussed this a bit with Jon; we'll use a slightly different approach
any update on implementing the different approach ?
Created attachment 222872 [details] [review] display: Delay focus changes in focus-follows-mouse mode Moving focus immediately on crossing events as we currently do in focus-follows-mouse mode may trigger a lot of unwanted focus changes when moving over unrelated windows on the way to a target. Those accidental focus changes prevent features like GNOME Shell's application menu from working properly and are visually expensive since we now use a very distinct style for unfocused windows. Instead, delay the actual focus change until the pointer has stopped moving.
Without actual testing from a focus-follows-mouse user i'm unsure if this is a good idea compared to just using the no-app-menu code in GTK+ that puts the app menu in the window. Clearly putting the app menu in the window is very ugly for apps designed against that idea - like the new GNOME apps - but making focus-follows-mouse focus changes annoying for people who use focus-follows-mouse would completely miss the point of having the option.
I've always been a bigger fan the other obvious approach for a top-menu -- don't switch what's in the global menu unless there's a key/button-press in the newly focused window.
(In reply to comment #11) > I've always been a bigger fan the other obvious approach for a top-menu -- > don't switch what's in the global menu unless there's a key/button-press in the > newly focused window. So you go to the overview, activate a window, and then you have to click again on the active window to get the app menu?
To give more details why I'm worried about this - a very typical focus follows mouse user is an artist with windows on two large monitors that: - React to clicks with drawing - React to shortcuts to change tools The user wants to be able to change shortcuts on the window they are about to draw on but can't just reflexively click on windows since that will draw if they are already focused. What this patch will do is cause the wrong thing to happen if the user hasn't paused their motion and held it without moving a pixel for 100-200ms. If the timeout and slop (I don't see a slop in this patch) are tuned right, maybe that work out naturally, but it's definitely of considerable concern.
(In reply to comment #12) > (In reply to comment #11) > > I've always been a bigger fan the other obvious approach for a top-menu -- > > don't switch what's in the global menu unless there's a key/button-press in the > > newly focused window. > > So you go to the overview, activate a window, and then you have to click again > on the active window to get the app menu? No. You already clicked on the active window to explicitly select it.
(In reply to comment #10) > Clearly putting the app menu in the window is very ugly for apps designed > against that idea - like the new GNOME apps Yeah, and it doesn't address the backdrop style either - I'd really prefer to do better. > but making focus-follows-mouse > focus changes annoying for people who use focus-follows-mouse would completely > miss the point of having the option. True, but the switch is almost instant when mouse movement stops - is it really common to type and move the mouse at the same time? I guess we could also adjust the heuristic to trigger when the mouse movement gets slower than some threshold, which is probably better anyway. Of course I'm not an actual f-f-m user myself ...
I have been using it for ~20 minutes and the current timeout is indeed a concern, I have now dropped it to 50ms (I tried 100ms before) and it's starting to feel comfortable, I'll keep on using it that way and report.
I've been using it for a couple days at 50ms now, and managed to forget I was using it, but I still have no issue getting to the application menu. It occurred to me that it might be nice if keyboard activity would just trigger the re-focus behavior. IE, don't focus the window you pointed at until it would actually matter. That would seem to: a) allow FFM to work with application menus b) completely remove that gap where there could be a problem Is there anything wrong with that approach? I suppose it would visually look like your typing would go to the wrong window until you typed. OTOH, maybe it would well in conjunction with the patch in this bug?
(In reply to comment #17) > Is there anything wrong with that approach? I suppose it would visually look > like your typing would go to the wrong window until you typed. OTOH, maybe it > would well in conjunction with the patch in this bug? It is hard to implement in X, because the keyboard activity is not seen by the shell, it gets sent to the focused application directly.
I've discussed this a bit with Owen yesterday. Here's a few thoughts: - We don't want to make things worse for focus-follows-mouse users whose workflow may be interrupted by the delay. So, we should at a minimum have a knob that lets us adjust the delay, all the way down to 0 (ie current behaviour). - We should make sure that touching down with a stylus or similar touch device is not subject to delays, but focuses the window the touched window right away. - If we had XI2, it might be nice to restrict he delay to apply to actual mice.
Oh, and we should probably reduce the default timeout to match what our early testers (thanks!) indicated was comfortable.
(In reply to comment #19) > I've discussed this a bit with Owen yesterday. > > Here's a few thoughts: > > - We don't want to make things worse for focus-follows-mouse users whose > workflow may be interrupted by the delay. So, we should at a minimum have a > knob that lets us adjust the delay, all the way down to 0 (ie current > behaviour). Mmmh, not exactly sure the timeout is the right setting to expose - without any special treatment of 0, the behavior does not match the current one: instead of moving focus immediately, we check for stopped pointer movement as often as possible. So maybe a boolean setting makes more sense? Conceptually an idle handler would probably be better than the timeout anyway, I was just worried about the performance impact. > - We should make sure that touching down with a stylus or similar touch device > is not subject to delays, but focuses the window the touched window right away. Don't we interpret those events as clicks?
(In reply to comment #21) > (In reply to comment #19) > > I've discussed this a bit with Owen yesterday. > > > > Here's a few thoughts: > > > > - We don't want to make things worse for focus-follows-mouse users whose > > workflow may be interrupted by the delay. So, we should at a minimum have a > > knob that lets us adjust the delay, all the way down to 0 (ie current > > behaviour). > > Mmmh, not exactly sure the timeout is the right setting to expose - without any > special treatment of 0, the behavior does not match the current one: instead of > moving focus immediately, we check for stopped pointer movement as often as > possible. So maybe a boolean setting makes more sense? Conceptually an idle > handler would probably be better than the timeout anyway, I was just worried > about the performance impact. So, there is no know for how long the pointer has to stop before we switch ? Anyway, a boolean sounds good. > > - We should make sure that touching down with a stylus or similar touch device > > is not subject to delays, but focuses the window the touched window right away. > > Don't we interpret those events as clicks? I would think so.
Created attachment 224559 [details] [review] display: (Optionally) delay focus changes in focus-follows-mouse mode (In reply to comment #22) > (In reply to comment #21) > > So maybe a boolean setting makes more sense? Conceptually an idle > > handler would probably be better than the timeout anyway, I was just worried > > about the performance impact. > > So, there is no know for how long the pointer has to stop before we switch ? > > Anyway, a boolean sounds good. I just tried to simply change the timeout to an idle, and it doesn't really work - no matter how fast I throw the pointer up to the panel, I always get a focus change. So I guess making the timeout configurable would work after all, however I still went with the boolean - not least because it seems a bit easier to come up with a preference name (not that I'm particularly happy with the name I came up with here) ... > > > - We should make sure that touching down with a stylus or similar touch device > > > is not subject to delays, but focuses the window the touched window right away. > > > > Don't we interpret those events as clicks? > > I would think so. Good, than it should just work.
Created attachment 224560 [details] [review] main: Override focus-change-on-pointer-rest preference The application menu is currently unusable with non-maximized windows when using focus-follows-mouse mode. Override mutter's focus-change-on-pointer-rest preference, so that the actual focus change is delayed until the pointer stops moving.
Oh, also I played around a bit with different timeouts - I was only starting to get problems reaching the menu at about 10ms, so instead of the suggested timeout of 50 I've lowered it to 25 now ...
Florian, did you want to land this ?
This patch is a major major improvement for us focus-follow-mousers, thanks. Any chance that we can get it into 3.6.x (aka F18) ?
Florian, can we land this soon ?
(In reply to comment #28) > Florian, can we land this soon ? I'd love that, but I won't review my own patches :-)
The patch looks mostly fine to me. The issue is whether we've stuck this in front of some users and they've had a chance to OK it.
There are users in comment 16, comment 17 and comment 27
Review of attachment 224559 [details] [review]: Looks fine with minor style issues. ::: src/core/display.c @@ +1627,3 @@ +static gboolean +window_focus_on_pointer_rest_callback (gpointer data) { + MetaFocusData *focus_data; Surrounding code all uses 2-space indentation.
Review of attachment 224560 [details] [review]: Sane enough for me.
Comment on attachment 224559 [details] [review] display: (Optionally) delay focus changes in focus-follows-mouse mode Attachment 224559 [details] pushed as 59bc5b7 - display: (Optionally) delay focus changes in focus-follows-mouse mode
Attachment 224560 [details] pushed as 3fdc8bf - main: Override focus-change-on-pointer-rest preference Pushing after string freeze approval; if this approach proves problematic in testing and we need a better heuristic / more tweaks, we can file that separately, so closing for now.