GNOME Bugzilla – Bug 591639
application_based mode improvements
Last modified: 2012-05-04 21:04:20 UTC
If you set application_based to true it doesn't seem to work as advertised. I've written about some of the ways I think this mode should work in: http://www.gnome.org/~mccann/shell/design/GNOME_Shell-20090705.pdf From that document one thing we'd like to be able to do: Windows must be able to be clicked to bring them into the foreground and in order for them to receive keyboard input focus (ie. make active). This is particularly important for windows that are partially visible. It can be difficult to find or identify an area to click in an unfocused window (particularly when overlapped or partly obscured) that won't be responsive to the click itself. This is even more difficult for windows without window decorations or when the decorations are obscured. In many cases forwarding clicks can have serious unintended consequences. So, most windows should not be responsive to pointer clicks unless they are already in the foreground. Scroll wheel events are not subject to the same issues and since they may be desirable even for unfocused windows they should always be allowed. There are, however, some cases where sending click events to windows not on top of the window order may be desirable or necessary. For example, any application with a multiple window workflow such as an Image Editor or any application with floating tool palettes. So, for this to work, the visual appearance of the window should indicate a) if it has keyboard input focus b) whether the window is responsive to mouse clicks. Applications must have a way to tell the window manager whether pointer events should be forwarded to an unfocused window. The unfocused window may allow one of the following: 1. should never receive clicks 2. should receive clicks when any window from the same application is in focus (eg. _NET_WM_WINDOW_TYPE_UTILITY) 3. should receive clicks when a _NET_WM_WINDOW_TYPE_UTILITY window of the same application is active 4. should always receive clicks So the follow window states are possible: 1. active window 2. inactive and click forwarding is allowed 3. inactive and click forwarding is not allowed
Another case that may be related to application mode is the following example: When I close an Evolution message display window the main Evolution window should be brought to the top of the stack.
I guess we probably won't do any of this stuff as part of this mode. Will close.