After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 678169 - make 'focus follows mouse' work
make 'focus follows mouse' work
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
3.6.1
Depends on:
Blocks:
 
 
Reported: 2012-06-15 14:35 UTC by Matthias Clasen
Modified: 2012-10-11 14:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
panel: Delay app-menu changes when using focus-follows-mouse (2.13 KB, patch)
2012-06-20 18:20 UTC, Florian Müllner
needs-work Details | Review
display: Delay focus changes in focus-follows-mouse mode (9.68 KB, patch)
2012-08-29 21:34 UTC, Florian Müllner
none Details | Review
display: (Optionally) delay focus changes in focus-follows-mouse mode (13.71 KB, patch)
2012-09-17 23:12 UTC, Florian Müllner
committed Details | Review
main: Override focus-change-on-pointer-rest preference (1.88 KB, patch)
2012-09-17 23:18 UTC, Florian Müllner
committed Details | Review

Description Matthias Clasen 2012-06-15 14:35:50 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.
Comment 1 Florian Müllner 2012-06-15 14:51:50 UTC
(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)
Comment 2 Matthias Clasen 2012-06-19 11:17:23 UTC
why not attach it ?
Comment 3 Florian Müllner 2012-06-19 11:19:01 UTC
Sure, will do in a bit (both approaches will need work though)
Comment 4 Florian Müllner 2012-06-20 18:20:25 UTC
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)
Comment 5 Matthias Clasen 2012-07-03 00:33:30 UTC
Whats the next step here ?
Comment 6 Matthias Clasen 2012-07-10 12:38:10 UTC
to answer myself: discuss with designers at ux hackfest pre-guadec
Comment 7 Florian Müllner 2012-08-01 13:12:02 UTC
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
Comment 8 Matthias Clasen 2012-08-27 14:10:44 UTC
any update on implementing the different approach ?
Comment 9 Florian Müllner 2012-08-29 21:34:12 UTC
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.
Comment 10 Owen Taylor 2012-08-30 19:39:15 UTC
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.
Comment 11 Jeremy Nickurak 2012-08-30 19:47:17 UTC
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.
Comment 12 Florian Müllner 2012-08-30 19:52:22 UTC
(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?
Comment 13 Owen Taylor 2012-08-30 19:54:42 UTC
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.
Comment 14 Jasper St. Pierre (not reading bugmail) 2012-08-30 20:01:02 UTC
(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.
Comment 15 Florian Müllner 2012-08-30 20:02:56 UTC
(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 ...
Comment 16 Frederic Peters 2012-08-30 20:20:45 UTC
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.
Comment 17 Jeremy Nickurak 2012-09-04 17:28:41 UTC
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?
Comment 18 Matthias Clasen 2012-09-04 22:38:02 UTC
(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.
Comment 19 Matthias Clasen 2012-09-07 11:37:11 UTC
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.
Comment 20 Matthias Clasen 2012-09-07 11:37:55 UTC
Oh, and we should probably reduce the default timeout to match what our early testers (thanks!) indicated was comfortable.
Comment 21 Florian Müllner 2012-09-11 15:08:20 UTC
(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?
Comment 22 Matthias Clasen 2012-09-13 12:08:22 UTC
(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.
Comment 23 Florian Müllner 2012-09-17 23:12:22 UTC
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.
Comment 24 Florian Müllner 2012-09-17 23:18:24 UTC
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.
Comment 25 Florian Müllner 2012-09-17 23:27:16 UTC
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 ...
Comment 26 Matthias Clasen 2012-10-01 15:24:13 UTC
Florian, did you want to land this ?
Comment 27 Olivier Crête 2012-10-05 15:54:23 UTC
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) ?
Comment 28 Matthias Clasen 2012-10-10 11:40:43 UTC
Florian, can we land this soon ?
Comment 29 Florian Müllner 2012-10-10 20:40:21 UTC
(In reply to comment #28)
> Florian, can we land this soon ?

I'd love that, but I won't review my own patches :-)
Comment 30 Jasper St. Pierre (not reading bugmail) 2012-10-10 21:30:43 UTC
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.
Comment 31 Matthias Clasen 2012-10-11 02:20:24 UTC
There are users in comment 16, comment 17 and comment 27
Comment 32 Jasper St. Pierre (not reading bugmail) 2012-10-11 02:37:09 UTC
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.
Comment 33 Jasper St. Pierre (not reading bugmail) 2012-10-11 02:37:26 UTC
Review of attachment 224560 [details] [review]:

Sane enough for me.
Comment 34 Florian Müllner 2012-10-11 14:32:30 UTC
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
Comment 35 Florian Müllner 2012-10-11 14:39:03 UTC
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.