GNOME Bugzilla – Bug 133046
Add a focus type API
Last modified: 2013-11-12 16:15:52 UTC
In addition to rejecting all focus offerings and conditionally rejecting focus for DnD, there exists another way to handle focus: rejecting focus from events on any part of a window (excluding the frame). This may be used by an application which presents a utility window or "floating palette", such as Glade, to allow the user to select items or tools with a click that does not steal focus away from the primary application window. The Gimp could use this, if they didn't put a menubar in the palette window or allow docking into it those items which may require keyboard input. A completely unfocusable window used for this purpose would be deleterious to keyboard access. Using a window manager that does not send WM_TAKE_FOCUS messages to globally active windows upon client area clicks ( bug #133034 ), the WM_TAKE_FOCUS message may be taken as indication that focus was offered by keyboard or some proxy such as the frame. An API to provide all three might use an enumeration property on Gtk window, e.g.: typedef enum { GTK_WINDOW_FOCUS_TYPE_NORMAL, /* default */ GTK_WINDOW_FOCUS_TYPE_PALETTE, GTK_WINDOW_FOCUS_TYPE_OUTPUT_ONLY } GtkWindowFocusType; The window type _NET_WM_WINDOW_TYPE_UTILITY does not exactly match the focus type of a palette because utility windows may contain items which require keyboard input. This, along with changes for raiseless DnD and modal dialogs requested in other bug reports, covers most (probably all) of the interesting uses of the globally active input model. All together, they provide for good interaction without requiring toolkit users to understand the horrors of X11 input handling.
This might be useful for panels too. They should generally not be focused unless the user clicks in eg. an entry.
When I proposed this and related changes, I was trying to find a way to keep the API as simple as possible and this in particular was a way to avoid exposing some underlying functions. Because changes would have to be made at or around GtkWidget, because a special container widget could serve the same purpose as a palette, and because this would ultimately be redundant, I'm marking this not a bug. In case it's missing from other bug reports, this is redundant because, when GtkWidget supports globally active input, each widget will be able to set or to not set focus when it receives a button press. Creating a palette window can be done by just making sure all the widgets in it, including the GtkWindow itself, do not set focus on button press.