Red Hat Bugzilla – Bug 490374
rise_on_click is a no-op
Last modified: 2014-06-18 05:11:02 EDT
There's no UI to toggle rise_on_click, use gconf-editor.
Oddly, it works as expected in Ubuntu Intrepid. Might be because of some rogue patch, or a compile-time option.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
I also have noticed this. I have only a few major gripes with MS Windows, and the auto-raise-on-click is one of them. And I also just came from Ubuntu 9.10 and it worked fine there also. And I'm using rawhide Fedora 12 beta.
And I would think it should be priority medium, since it is not a feature request. I do bear in mind that since it isn't a popular bug, it probably isn't observed by most people, but it was in fact intended to function and it does function as intended on Ubuntu.
"Severity Three issues are defined as causing partial non-critical functionality loss, or issues which impair some operations but allow the customer to perform their critical tasks. This may be a minor issue with limited loss or no loss of functionality and limited impact to the customer's functionality."
(In reply to comment #3)
Scratch that. It already is medium severity. I was confusing priority and severity.
See the note in the docs for the GConf key:
"... This option is currently disabled in click-to-focus mode ..."
It works fine for me testing it with sloppy or mouse mode, so I assume that's what you are seeing. Not going to deviate from upstream on the above so closing WONTFIX.
Yes, that note is there. I had taken note of it long ago.
I don't use sloppy or mouse mode, never have, and I have no interest to begin now. Here's why I prefer raise-on-click to be off: If I'm working in a shell, reviewing a man page in my browser or any other documentation that is in any other window, and I need to scroll down, I won't be able to type anything in my xterm without moving the mouse back to it, if I use mouse or sloppy as you say.
Alternatively, I would find it perfectly acceptable if the documentation window that I was reading was in the foreground and I had the xterm or other editor window in the background--even if I couldn't see what I was entering--without going through a hoop that I had to go through with Ubuntu.
To be more clear perhaps, the expected behavior for when raise_on_click=on is the actual behavior for either when raise_on_click=on or off.
As I said before, this functionality worked fine with Ubuntu for as long as I used it, since 7.10 all the way to 9.10. So are you saying that Ubuntu did patch from the upstream in order to get this functionality? If so, I suppose I could register a bug on GNOME's bugzilla, but I quickly searched for "raise_on_click" and none of the bugs obviously indicated to me clearly that the feature is so broken that it isn't intended to work. Maybe I was not reading correctly.
See https://bugzilla.gnome.org/show_bug.cgi?id=326156 for lots of discussion on the subject; don't know if you'll find it satisfactory.
(For the use case: what I usually do is use the window menu to set documentation window (or whatever) always on top. It works pretty well but obviously is hard to discover; on the other hand, so is changing some obscure GConf key.)
Looking at their package, yes, Ubuntu does carry a patch to modify the behavior:
diff -Nur -x '*.orig' -x '*~' metacity-2.27.1/src/core/prefs.c metacity-2.27.1.new/src/core/prefs.c
--- metacity-2.27.1/src/core/prefs.c 2009-09-10 16:46:24.000000000 +1000
+++ metacity-2.27.1.new/src/core/prefs.c 2009-09-10 16:46:24.000000000 +1000
@@ -1258,10 +1258,7 @@
- /* Force raise_on_click on for click-to-focus, as requested by Havoc
- * in #326156.
- return raise_on_click || focus_mode == META_FOCUS_MODE_CLICK;
+ return raise_on_click;
as I said above I'm not going to deviate from upstream on this.