path: root/doc/how-to-get-focus-right.txt
diff options
authorElijah Newren <>2005-02-22 02:11:25 +0000
committerElijah Newren <>2005-02-22 02:11:25 +0000
commit612507260a550ff2381bfcbbe32f9bab62650fd9 (patch)
treede776ecb45e5d1a64c6bce4109a089bb65da5ab2 /doc/how-to-get-focus-right.txt
parentad99427b49e80db15413aaa4ce65c540aff565b4 (diff)
Handle keynav vs. mousenav in mouse and sloppy focus modes. Fixes #167545.
2005-02-21 Elijah Newren <> Handle keynav vs. mousenav in mouse and sloppy focus modes. Fixes #167545. * doc/how-to-get-focus-right.txt: Update due to this new method for handling keynav vs. mousenav, plus various other updates that I previously forgot. * src/display.h: (struct _MetaDisplay): add a mouse_mode boolean * src/display.c: (meta_display_open): initialize mouse_mode to true, (event_callback): have EnterNotify and LeaveNotify events set mouse_mode to true when focusing a window * src/keybindings.c: (process_tab_grab): set mouse_mode to false when using alt-tab/alt-esc, (do_choose_window): likewise, (do_handle_move_to_workspace): set mouse_mode to false on move-window-to-workspace-<n> keybindings * src/window.c (idle_calc_showing): if we're in keynav mode while using sloppy or mouse focus, use metacity_sentinel to avoid EnterNotify events being generated from events other than mouse movement. * src/workspace.c (meta_workspace_activate_with_focus): add a FIXME in a potentially duplicate section of code, (meta_workspace_focus_default_window): use the same focus choice as click-to-focus if in keynav mode.
Diffstat (limited to 'doc/how-to-get-focus-right.txt')
1 files changed, 46 insertions, 5 deletions
diff --git a/doc/how-to-get-focus-right.txt b/doc/how-to-get-focus-right.txt
index 9d9ab69..ccef493 100644
--- a/doc/how-to-get-focus-right.txt
+++ b/doc/how-to-get-focus-right.txt
@@ -79,9 +79,26 @@ to alert the user that there is a window to work with:
Additionally, the user may decide to use the keyboard instead of the mouse
to navigate between windows (referred to as "keynav"). This poses no
problems for click-to-focus (because the same invariant can be
-maintained), but for sloppy and mouse focus it means that EnterNotify
-and LeaveNotify events should be ignored (they can be generated
-without using the mouse, for example, by grabs).
+maintained), but for sloppy and mouse focus it requires extra work to
+attempt to handle the INHERENTLY CONFLICTING CONSTRAINTS. Metacity does
+this by having a mouse_mode boolean used to determine which of the two
+sets of invariants holds. This mode is set according to which method was
+most recently used to choose a focus window:
+ 1) When receiving EnterNotify/LeaveNotify events from mouse movement, set
+ mouse_mode to TRUE.
+ 2) When using keynav to choose a focus window (e.g. alt-tab, alt-esc,
+ move-window-to-workspace keybindings), set mouse_mode to FALSE.
+ 3) When handling events that don't choose a focus window but rather need
+ a focus_window chosen for them (e.g. switch-to-workspace keybindings),
+ don't change the mouse_mode and just use the current value.
+Note that grabs present a special case since they can generate EnterNotify
+and LeaveNotify events without using the mouse, thus these events should be
+ignored when the crossing mode is NotifyGrab or NotifyUngrab. THIS
+when trying to mix-and-match between mousenav and keynav simultaneously
+that cause problems; but it appears to be the most reasonable tradeoff and
+works well in most cases, especially if the user sticks to just mousenav
+for a long time or just keynav for a long time.
Finally, windows of type WM_DOCK or WM_DESKTOP (e.g. the desktop and
the panel) present a special case, at least partially due to the lack
@@ -103,7 +120,8 @@ To read more about the bugs that inspired these choices:
Also, the EWMH spec, especially the parts relating to _NET_WM_USER_TIME
- Modal vs. non-modal dialogs that get denied focus when mapped
- - Ignoring EnterNotify and LeaveNotify events during keynav
+ - Mousenav vs. Keynav in mouse and sloppy focus modes
- Not focusing panels
@@ -121,6 +139,7 @@ the ones I'm the most familiar with):
bug 95747 should ignore EnterNotify events with NotifyInferior detail set
bug 97635 sticky windows always keep focus when switching workspaces
bug 102665 a window unminimized from the tasklist should be focused
+ bug 107347 focus windows that manually position themselves too
bug 108643 focus in MRU order instead of stack order
bug 110970 moving a window to another workspace loses focus
bug 112031 closing a dialog can result in a strange focus window
@@ -128,6 +147,7 @@ the ones I'm the most familiar with):
bug 120100 panel shouldn't be focused after workspace applet usage
bug 123803 need final EnterNotify after workspace switch (see also 124798)
bug 124981 focus clicked window in pager only if on current workspace
+ bug 125492 catch the xserver unfocusing everything and fix its braindeadedness
bug 128200 focus correct window on libwnck window minimize (see 107681 too)
bug 131582 fix race condition on window minimize/close
bug 133120 wrong window focused when changing workspaces
@@ -148,6 +168,18 @@ the ones I'm the most familiar with):
bug 151990 prevent focus inconsistencies by only providing one focus method
bug 151996 modal dialogs denied focus should not be lowered
bug 152000 fix race on window close followed by rapid mouse movement
+ bug 152004 ways to handle new window versus mouse invariants
+ bug 153220 catch the root window getting focus and reset to default window
+ bug 157360 focus parents of dismissed transient windows in preference to
+ the window that most recently had focus
+ bug 159257 focus the desktop when showing it
+ bug 160470 don't focus panels on click
+ bug 163450 correct highlighting in workspace switcher popup
+ bug 164716 refuse to focus a window with a modal transient, and focus
+ the transient instead
+ bug 166524 avoid new windows being obscured by the focus window
+ bug 167545 mousenav vs. keynav in mouse and sloppy focus modes
+ <a massive heap of bugs relating to focus stealing prevention...>
Addendum on sloppy and mouse focus
@@ -156,7 +188,7 @@ Addendum on sloppy and mouse focus
1) Keynav doesn't maintain the same invariants as mouse navigation
for these focus modes; switching back and forth between
- navigation methods, therefore, may appear to have
+ navigation methods, therefore, may have or appear to have
inconsistencies. Examples:
a) If the user uses Alt-Tab to change the window with focus, then
starts to move the mouse, at that moment the window where the
@@ -182,6 +214,15 @@ Addendum on sloppy and mouse focus
containing the menu) but is one of those hard-to-get-right
keynav and mouse focus mixture cases. (See bug 101190 for
more details)
+ d) Similar to (c), moving the mouse off the menu doesn't immediately
+ focus the window that the mouse goes over, due to an application
+ grab (we couldn't change this and wouldn't want to, but
+ technically it does break the invariant).
+ e) If mouse_mode is off and the user does something to cause focus to
+ change (e.g. switch workspaces, close or minimize a window, etc.)
+ and simultaneously tries to move the mouse, the choice of which
+ window to focus is inherently race-y. (You probably can't satisfy
+ both keynav and mousenav invariants simultaneously...)
2) The sloppy/mouse invariants are often not strictly maintained;
for example, we provide an exception to the invariant for newly
mapped windows. (Most find that not allowing this exception is