This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 490374 - rise_on_click is a no-op
rise_on_click is a no-op
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: metacity (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Søren Sandmann Pedersen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-15 16:19 EDT by Bernie Innocenti
Modified: 2014-06-18 05:11 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-16 11:36:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 326156 None None None Never
Gentoo 88462 None None None Never

  None (edit)
Description Bernie Innocenti 2009-03-15 16:19:05 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.
Comment 1 Bug Zapper 2009-06-09 08:16:22 EDT
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 2 Derek Schmidt 2009-11-11 20:23:38 EST
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.
Comment 3 Derek Schmidt 2009-11-11 22:58:26 EST
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."
Comment 4 Derek Schmidt 2009-11-11 23:00:46 EST
(In reply to comment #3)
Scratch that. It already is medium severity. I was confusing priority and severity.
Comment 5 Owen Taylor 2009-11-16 11:36:33 EST
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.
Comment 6 Derek Schmidt 2009-11-16 22:30:08 EST
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.
Comment 7 Owen Taylor 2009-11-17 13:26:14 EST
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 @@
 gboolean
 meta_prefs_get_raise_on_click (void)
 {
-  /* 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;
 }
 
 const char*
===

as I said above I'm not going to deviate from upstream on this.

Note You need to log in before you can comment on or make changes to this bug.