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 498747 - Raise externally focused windows
Raise externally focused windows
Status: RESOLVED NOTABUG
Product: metacity
Classification: Other
Component: general
2.20.x
Other Linux
: Normal normal
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on:
Blocks:
 
 
Reported: 2007-11-21 13:30 UTC by Josselin Mouette
Modified: 2007-11-24 03:48 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20



Description Josselin Mouette 2007-11-21 13:30:15 UTC
When /apps/metacity/general/raise_on_click is on, clicked windows are raised of course, but it also affects windows that are focused by an external event. When it is set to false, such windows take the focus but aren't raised.

This is very annoying with nautilus spatial windows or with tomboy windows. When you want to jump to an already opened window, it gets the focus but remains hidden under the others.

Please make raise_on_click affect only, as the name says, what happens when you click a window.
Comment 1 Thomas Thurman 2007-11-21 17:44:55 UTC
Solution: do what the docs tell you, and don't turn raise_on_click on. See also <http://blogs.gnome.org/metacity/2007/11/21/raise-on-click/>.
Comment 2 Thomas Thurman 2007-11-21 17:47:57 UTC
...don't turn raise_on_click off, even.
Comment 3 Josselin Mouette 2007-11-22 10:36:55 UTC
I don't understand why you keep a broken behavior, then. The fact you know it is broken and you say it on a blog doesn't make it less broken.

Instead of keeping a GConf key that - indeed - breaks the behavior in many cases, why don't you replace it by another setting that would, this time, be useful?

Raising windows on click is a very annoying behavior, especially when you jump between a fullscreen application and a windowed one. You need to be able to deactivate it. And deactivating it shouldn't break window raising in weird and random ways.

I'd understand if you said "this is hard to fix" or "we consider it a feature request". But you can't say this issue doesn't exist.
Comment 4 Elijah Newren 2007-11-22 15:23:50 UTC
The point of raise_on_click=off is that it's simple to raise a window by
alt-clicking on it (or alt-tabbing or clicking on the window decorations or clicking in the tasklist...).  If a window is raised as a side-effect of some
unrelated action, however, it's a royal pain to restack windows to the way they were before.

The claims that the feature is "broken" is because
  (1) There are bugs in other places: apps use _NET_ACTIVE_WINDOW when they
      shouldn't (because we don't have the appropriate API in some cases),
      we don't appropriately treat clicks that start drags yet, etc.
  (2) Users trying to make things that work despite the bugs (see (1) above),
      will complain to app authors and have app authors come up with workarounds,
      that (a) break things further, and (b) undermine this feature.

It is completely unreasonable to have app authors wasting their time "working around" other bugs and it'd be downright damaging to this actual feature.  To avoid that, I wrote the claims that this feature is "broken".  It's a lot easier than explaining the nasty intricate details.

But, in reality, this key is NOT broken.  Other things are.  The solution is not to break this feature, it's to fix the other bugs.  Unfortunately, it ain't easy.
Comment 5 Josselin Mouette 2007-11-22 15:31:03 UTC
Thanks for the explanations. Could you please point me to these "other bugs", if they are referenced in bugzilla ?
Comment 6 Havoc Pennington 2007-11-24 03:48:14 UTC
As a side note, a handy tip: if you have a help window or something and don't want it to go below your main window, use the Always On Top feature.