GNOME Bugzilla – Bug 133040
Support more flexible focus policies
Last modified: 2013-02-13 03:59:34 UTC
The patch accepted at bug #64613 uses the globally active input model (GA) only for windows which have set accept_focus to FALSE. GA should be used for all windows leaving accept_focus to determine only the response to the WM_TAKE_FOCUS message. Taken with Metacity bug #133034 , this will require really setting the focus from Gtk+ when appropriate (some ButtonPress and ButtonRelease events). Really setting focus from Gtk+ requires the part of the rejected patch at bug #64613 which sends a SetInputFocus request to the X server. Generally, the appropriate time to set input focus is on a ButtonPress event. Some widgets should defer until a ButtonRelease after no drag has started. See bug #133037 for a way to determine whether the event widget calls for deferring the SetInputFocus request.
*** Bug 133041 has been marked as a duplicate of this bug. ***
*** Bug 133045 has been marked as a duplicate of this bug. ***
*** Bug 133042 has been marked as a duplicate of this bug. ***
I'd really like to see this addressed from the standpoint of: - What capabilities are we trying to provide to the application writer. - How do we work with the window manager on X11 and with the windowing system on other platforms to achieve that. Rather than point-by-point details of API and window manager interaction.
Bug #133046 addresses the capabilities provided to application authors. But an important reason to switch to the globally active input model is to fix focus handling for modal dialogs. You may say the new capabilities are a beneficial side-effect of fixing focus that way, or that they are a reason to fix focus that way. Please see #133046; what follows is how we work with the WM on X11 to achieve what is described there. To achieve output-only windows on X11, we do what is done as of 2.4, with gtk_window_set_accept_focus(). This requires nothing more than ICCCM-compliance from the window manager. Palette-style focus would be the same as output-only, if we did not require keyboard accessibility. It requires 3 window manager policies, in addition to ICCCM-compliance: 1) click-to-focus 2) Do not send WM_TAKE_FOCUS for clicks in the client area of globally active windows. (metacity bug #133034 ) 3) Do not prevent any (unmodified) clicks in the client area of unfocused globally active windows from reaching the window. (metacity bug #133034 covers this too.) Without policies 1 and 2, palettes would behave as they do now. Policy 2 serves to make a distinction between focus setting by client-area clicks and focus setting by any other means. Without policy 3, the user would have to issue an extra click to do anything in any unfocused window; prelighting without focus would be a false indicator. (BTW, palette-style focus should only be used on window of the type _NET_WM_WINDOW_TYPE_UTILITY. but should not be used on all of them. I don't know whether you want to enforce such a policy in code. I would.) Normal-style focus is what we have now. With the three policies required for palette-style focus, it becomes "what we have now, plus focus-less DnD". With one additional policy, raise-on-focus, it becomes "what we have now, plus raise-less DnD". From the application's perspective, on any platform, what we need to know is what user action has caused a focus-related action. The important distinction on X11 is ButtonPress in the client area vs. everything else. I suspect that on win32 it is WM_MOUSEACTIVATE vs. everything else.
A minor correction: Some other _NET_WM_WINDOW_TYPEs might also use palette-style focus: DESKTOP, DOCK, TOOLBAR, and MENU. I just forgot those existed, since most apps wouldn't set them directly.
closing old bugs