After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 591639 - application_based mode improvements
application_based mode improvements
Status: RESOLVED INVALID
Product: mutter
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2009-08-13 00:54 UTC by William Jon McCann
Modified: 2012-05-04 21:04 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description William Jon McCann 2009-08-13 00:54:27 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
Comment 1 William Jon McCann 2010-02-03 17:59:14 UTC
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.
Comment 2 William Jon McCann 2012-05-04 21:04:20 UTC
I guess we probably won't do any of this stuff as part of this mode. Will close.