GNOME Bugzilla – Bug 167545
Move window to workspace keybindings lose window focus
Last modified: 2005-02-22 04:07:15 UTC
If you use a keybinding to move a window to another workspace in sloppy focus mode, it window loses focus when you get the the new workspace. This used to work (it was the reason for the METACITY_SENTINEL property) but now it seems to focus the window under the pointer. The window should stay focused as you move to the other workspace, especially if you want to move it more than one workspace.
Hehe, sloppy focus is more crackful than mouse focus! (Note that this works fine if the window is under the mouse at the time you decide to move it to another workspace). Anyway, this is another case of keynav-should-be-different-than-focus-follows-mouse (note that keeping the focus on the window that changed workspaces would violate the sloppy focus invariants mentioned in doc/how-to-get-focus-right.txt, so one could regard this behavior as intentional, though I think we should fix it). Anyway, I'll be writing a patch soon (I had already planned on it because of other issues, but it's nice to have this bug as a reason too) which will make switching between keynav and mouse usage work better in sloppy&mouse focus modes (won't change a think in click to focus). This bug will be one of the things it fixes.
Oops, wrong milestone. :-)
Okay, so I'm going to be long and detailed so that hopefully the patch I will attach in a minute will all make sense. First a rehash of the bugs this patch is designed to fix: - The one Rob mentioned above 1) In sloppy focus mode have the pointer on the desktop and the mru window focused 2) User decides to quickly move the focused window to workspaces to the right 3) User hits move-window-to-workspace-on-right keybinding 4) Mouse happens to enter a window on the inbetween workspace, which then gets focus (due to focus choice invariants for sloppy focus) 5) (Only a split second after step 3) User again hits move-window-to-workspace-on-right keybinding 6) User realizes they moved the window they wanted only one workspace to the right, and pulled a different window from the intermediate workspace to the target workspace. :-( - The one that bothers me 1) With mouse or sloppy focus set, decide to use keynav (i.e. alt-tab, alt-f4, etc.) for a while 2) 20 minutes later (and still only haveing used keynav), close a window 3) Notice that the window across the screen is chosen as the focus window because that's where the mouse is. :-( Proposed solution for this problem: Add the concept of "mouse_mode" (only relevant to sloppy and mouse focus) which is turned on by default, is switched back on whenever a window is focused due to EnterNotify/LeaveNotify events, and is turned off whenever a focus window is specified by keynav events. Details of solution: The crux of the patch I will attach in a minute is the following few lines in meta_workspace_focus_default_window(): - if (meta_prefs_get_focus_mode () == META_FOCUS_MODE_CLICK) + if (meta_prefs_get_focus_mode () == META_FOCUS_MODE_CLICK || + !workspace->screen->display->mouse_mode) focus_ancestor_or_mru_window (workspace, not_this_one, timestamp); else In other words, if using keynav then use the same focus choices as for click-to-focus. Otherwise, use the traditional sloppy or mouse focus choices. The majority of the remainder of the patch is setting or unsetting display->mouse_mode as appropriate and updating how-to-get-focus-right.txt (including a couple unrelated fixes for things I previously forgot to mention near the end of the file). The one really interesting part of the patch is the return of the metacity_sentinel in idle_calc_showing--but _only_ for sloppy and mouse focus modes when display->mouse_mode is false. Using it when mouse_mode is true would result in getting a return of some of the race conditions that its removal in bug 152000 was designed to fix. Granted, using the metacity_sentinal does add a race condition when keynav is being used, but one that was already there: users who had just been using keynav (and thus are expecting its invariants to hold) and doing something like switching workspaces _and_ simultaneously moving the mouse (thus trying to simultaneously get mouse invariants to hold) were already screwed with an inherent race anyway...
Created attachment 37759 [details] [review] Add a way to handle keynav vs. mousenav in mouse and sloppy focus modes
Comment on attachment 37759 [details] [review] Add a way to handle keynav vs. mousenav in mouse and sloppy focus modes mouse focus die die die ;-) Anyhow, looks reasonable given we have to live with that complexity.
This complexity is for both sloppy and mouse focus modes. ;-) I committed the patch.
die sloppy focus! die!