GNOME Bugzilla – Bug 152004
"Strict pointer mode" (whether to focus on map--see comments 7 & 14)
Last modified: 2006-04-12 18:59:01 UTC
This patch adds "strict pointer mode" which sledgehammer turns off all keynav heuristics, including focusing new windows, focusing default windows, etc. It is driven by customers who are used to mwm/4dwm and use legacy apps that don't have keynav anyhow and have zillions of little windows. The original request was for a bunch of individual settings (don't focus on map, do such-and-such on workspace switch, etc. etc.) and I collapsed it all into a single "mode" This patch is just to show the idea, it's not fully baked (it's vs. 2.4.55, I thought I had it vs. HEAD also but don't see it right now)
Created attachment 31338 [details] [review] patch for "strict pointer mode"
/me breathes a sigh of relief to learn that this is a different mode rather than a modification of the existing mouse and sloppy focus modes However, it seems kind of odd for two reasons: (1) I believe the patch in bug 135810 (already committed) combined with an option to have windows default to not focusing on map would already cover every change this patch makes; (2) I believe this patch would fall short of being a strict pointer mode because of the change in bug 110970 (i.e. bug 124798/bug 123803 would affect this strict pointer mode).
Doh, I fired off way too quick. Let me modify my above statements: (1) Actually there are more issues: (A) The patch in bug 152000 would also be needed to make strict pointer mode work. (B) The patch in bug 135810 combined with a don't-focus-on-map-by-default option may actually work better than the strict-pointer-mode in one case--if the user is using sloppy focus and closes a window and there is no window beneath the pointer, one would expect the mru window to get focus (similar to a workspace switch; see bug 135810). The strict-pointer-mode doesn't do that and may (I haven't checked closely) suffer from a "keyboard-lock" problem similar to the one in bug 147475 (due to lack of any window having focus). (C) focus-stealing-prevention makes not focusing on map a little weird since the DEMANDS_ATTENTION hint is set and the window is lowered in those cases. So the patch may have to do something about that. However, focus-stealing-prevention itself /might/ be a "good enough" fix that would remove the need to not-focus-on-map-unless-the-mouse-is-there. (Note the emphasis on might, I'm sure you'll still get customers requesting it, if they really do want a strict pointer mode) (2) Note that the patch in bug 110970 was committed as part of the 2.5.x series of Metacity, which is why no one would have noticed bug 124798/bug 123803 when using that strict pointer mode on rhel3.
Watching how many problems we have with the existing 3 focus modes, adding an additional two via this patch does seem a little worrisome. If we could change it to only a "whether to focus on map" then OK, but my worry is having to go back and add a zillion settings like "don't focus the mru window when closing a dialog", "don't focus mru window on workspace switch", etc. etc. so need to go through all those and get a sense. This patch is indeed known to cause "keyboard shortcuts stop working" problems, though I was hoping this fix would avoid that: 2003-09-26 Havoc Pennington <hp@redhat.com> * src/display.c (event_callback): when focus on root window becomes None, set it to something other than None so keybindings keep working and print a warning about how some application sucks. #84564 (event_callback): Fix debug spew to print focus event details properly (meta_display_open): when setting initial focus, always use RevertToPointerRoot and fix the focus if it's None or PointerRoot I think that fix wasn't in 2.4.55... Wow, once all this focus crap is fixed it feels like we need a freaking whitepaper on how it all works and why and what the alternatives were so we can properly evaluate future proposed bugs and changes... I'm really confused by now.
You don't need to worry about cases like "don't focus the mru window when closing a dialog" and "don't focus mru window on workspace switch". The reason you don't need to worry about them is the logic added in bug 135810. For sloppy and mouse focus, when a focused window becomes invalid, we specified that the new focus window should be: sloppy - focus the window containing the pointer if there is one, otherwise focus the mru window mouse - focus the window containing the pointer if there is one, otherwise focus the no_focus_window (Well, okay the no_focus_window part was added in bug 147475 because we can't just not focus any window--bug 147475 showed that there is at least one case when the catch-no-window-is-focused patch isn't quite sufficient) In other words, the window where the mouse is takes precedence--just as strict-pointer-mode would require. (Letting them take precedence also avoids race conditions, such as those found in bug 131582). I think your request for a "whitepaper" that explains everything would be helpful as well. So I'll attach one in a minute. I'm a little unsure about the "modal vs. non-modal newly mapped window which is denied focus" both because no one has commented on bug 151996 yet and because there may be other related cases that I have missed.
Created attachment 31342 [details] How to get focus right--all our current policies (text file)
I see, I think I somehow missed the big picture that we've cut over to always using strict pointer rules with sloppy/mouse focus on HEAD, with the exception of focusing new windows on map (or not). So nice, we can probably just skip this patch entirely. I'd say we shouldn't add a "focus on map" setting until we get the focus stealing prevention fully working and see how good it is. Thanks for the writeup, suggest adding it to doc/ and mention its existence in rationales.txt (maybe replace the mention of focus bugs with a pointer to this document)
Created attachment 31394 [details] Modifications to the how-to-get-focus-right file Okay, I'll add it to docs and update rationales.txt. I noticed some things that I thought would be useful to add to the writeup, so I've attached a patch regarding what I've changed in it. In summary: 1) We treat WM_DOCK and WM_DESKTOP windows differently (they are only focused on explicit click, and are effectively shuffled to the end of the list when considering a new window to focus), yet the writeup didn't reflect that. 2) There are invariants we are trying to maintain for each focus mode, but I didn't make that explicit before. I think doing that makes things clearer, and also motivates the choice for the new window to focus when the previous one goes away. 3) I thought it would be nice to have a write-up on the difficulties that come with sloppy and mouse focus methods so that we can point users to it if necessary. Anyway, holler if you see something that needs to be changed or something else I should add. I'm going to commit it to cvs in a minute.
Comment on attachment 31394 [details] Modifications to the how-to-get-focus-right file Looks nice, one other thing to mention is that you can focus panels/desktop with Ctrl+Alt+Tab, otherwise we'd have no way to keynav those.
Right, I forgot about that. I updated it in cvs.
Comment on attachment 31338 [details] [review] patch for "strict pointer mode" Since this doesn't apply against HEAD, I'm going to mark it as needs-work in order to get it off the patch-diligence report (http://bugzilla.gnome.org/reports/patch-diligence-report.cgi)
*** Bug 160589 has been marked as a duplicate of this bug. ***
*** Bug 161275 has been marked as a duplicate of this bug. ***
Wahoo! Russell Nelson (nelson crynwr com) suggested an alternative via email that would remove the need for any preference for focus-on-map by adjusting the placement algorithm appropriately: - when a new window should take focus on map, it gets positioned so that it is underneath the mouse. - when a new window should not take focus on map, it's placed so that it's NOT underneath the mouse. This is worth investigating to determine whether this can be part of a sane window placement algorithm. If so, this would be ideal because we'd get a "Just Works" environment with one less preference to muck things up.
> - when a new window should take focus on map, it gets positioned so that it is underneath the mouse. That presumes that it knows it should ttake focus on map. My brain is still wrapped around launching several windows from one (with thought time), and not having focus leave the window I'm in. That is, in xterm #1, launch 3 more xterms one at a time. Needing to refocus on xterm #1 between each one causes me pain. There is no way for metacity to know that I want it to do that, hence the need for a sledgehammer switch
LaMont: > There is no way for metacity to know that I want it to do that That's mainly because applications launched from a terminal aren't launched with startup-notification. There is a way to fix this to work without startup-notification (Soeren's suggestion--see bug 151984) which would make it so that as long as you are using a terminal that supports _NET_WM_USER_TIME and you keep typing before the window appears, then Metacity will know that you don't want the launched window to be focused. Note, however, that your entire scenario is a niche usage case restricted to launching applications from a terminal, whereas everything else in this bug is for more general usage cases. I'm not trying to say launching apps from a terminal is an unimportant case (because I am one of those niche users and I do feel your pain), it's just that we have to focus on getting other things right first. Besides, I believe there's a way to fix even this niche case without an ugly suboptimal sledgehammer switch.
LaMont: The best way to launch four xterms when you're using sloppy focus is by running ". xterms" and creating a shell script that looks like this: #!/bin/sh xterm& xterm& xterm& xterm&
Your write-up says "Most users want to interact with new windows right away, so these should typically be focused.", but it seems to me that the rest of the document presumes ALL users. Or perhaps not. In any case, let me add a vote for a "strict" mode. If I'm in a window, and a new window pops up, but not under my pointer, I certainly don't want my focus to be stolen away. To get the focus back, I have to move the pointer OUT then BACK again. This is very inconvenient, and very unnatural behaviour for the "mouse" focus_mode, IMHO. The only case where I personally will accept focus moving to a different window without my explicit consent, is where the currently focused application throws up a transient window (a Find dialog or similar). I guess I should add I'm just trying to switch to GNOME after having run the succession of rwm/twm/fvwm since 1990. This is really the only sticky point left.
(In reply to comment #18) > To get the focus back, I have to move the pointer OUT then BACK again. Actually, there are other ways to get focus back -- one of them being that you can also click on the window (which is also useful for cases like when you use alt-tab to switch focus to a window that isn't under the mouse, work with it for a while, then decide to start using the mouse and the window under it without alt-tabbing back).
Sure, but I'd have to move my hand to use the mouse, and that click is passed through to the application, so it's not a no-op. (e.g., in XTerm it will blank the selection.) Of course, Alt+Tab works, too, if you have it bound to switch_windows. But that means I have to be aware of the loss of focus, and actively perform an action (at the right time!) to undo the focus loss which I didn't want to happen in the first place. Getting the timing right is not easy either. When I'm typing along, it happens quite often that I finish the command just as the new window appears, so it receives the tail end of the command _and_ the Return. Which causes the new window to quickly disappear, unread, if it was an informational popup.
In metacity 2.15.x: gconftool-2 --set /apps/metacity/general/focus_new_windows --type string strict *** This bug has been marked as a duplicate of 326159 ***
*** Bug 321759 has been marked as a duplicate of this bug. ***
I object to marking this as a duplicate of bug 321759. this does not only apply when my focus happens to be in a terminal, windows can pop up randomly for many reasons. why would I want my focus behaviour to be different depending on what I point at? I want consistent behaviour, and the simplest way to get that is to let "strict" mean "strict".