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 599261 - Add a new_windows_always_on_top preference
Add a new_windows_always_on_top preference
Status: RESOLVED OBSOLETE
Product: metacity
Classification: Other
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on:
Blocks:
 
 
Reported: 2009-10-21 23:57 UTC by Owen Taylor
Modified: 2020-11-06 20:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Add a new_windows_always_on_top preference (5.73 KB, patch)
2009-10-21 23:57 UTC, Owen Taylor
none Details | Review
Apply new_windows_always_on_top to newly raised/activated windows (4.75 KB, patch)
2010-06-23 23:57 UTC, Owen Taylor
none Details | Review

Description Owen Taylor 2009-10-21 23:57:57 UTC
Continuing the trend of "patches to make Metacity lovers howl", here's
a preference to always put new windows on top, even when they are focus
denied.

The reasoning here is that given sufficiently much real-estate in the
form of large monitors and multihead, the current behavior where if
a window would overlap it is buried and flashed in the taskbar doesn't
work very well - the task bar is no longer in the user's peripheral
vision, and even if they notice it, it can be a long way to mouse to.

(A sophisticated user may know that a single tap of Alt-Tab will get
to the flashing window, but many users will not catch on to this.)

This preference (as noted in the GConf schema) is really meant for
mouse/sloppy focus where we more frequently break the relationship
of focused and on-top. But I don't think it makes sense to make it
a no-op for focus_mode=click. We do break that relationship
occasionally already even in that case, and its less confusing to
try the key and find you don't like it then to have the key do
nothing.

There's a bit of a dependency here on bug 599097 - this patch makes it
even more likely you'll get to the state where a window is under
the pointer but not focused, so having an easy way to recover from that
is nice.

In the case where the new window *completely* obscures the focus
window, it might be nice to focus the no-focus-window to avoid keystrokes
going to a hidden window, but I didn't want to add more code to
complete "completely obscures" just for an obscure preference. It would
be wrong to focus the no-focus-window if the new window is only a small
window that overlaps a bit of the focus window - that basically
reintroduces the annoyance of focus-stealing, if not the security threat.
Comment 1 Owen Taylor 2009-10-21 23:57:59 UTC
Created attachment 146010 [details] [review]
Add a new_windows_always_on_top preference

Add a /apps/metacity/general/new_windows_always_on_top preference.
When set, new windows are always placed on top, even if they are
denied focus.

This is useful on large screens and multihead setups where the
tasklist can be hard to notice and difficult to mouse to, so the
normal behavior of flashing in the tasklist is less effective.
Comment 2 Owen Taylor 2010-06-23 23:57:28 UTC
Created attachment 164454 [details] [review]
Apply new_windows_always_on_top to newly raised/activated windows

Testing revealed that this patch met its objectives; however, users
expected the consistent behavior to occur for windows that tried to
raise or focus themselves - these windows are "new to the user"
if not entirely new.

This add-on patch implements that.
Comment 3 André Klapper 2020-11-06 20:06:10 UTC
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years.

If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/

Thank you for reporting this issue and we are sorry it could not be fixed.