GNOME Bugzilla – Bug 154614
Consider removing the auto-raise preference from the user interface
Last modified: 2010-11-17 15:35:13 UTC
There are a few reasons I believe it would be a good idea to remove the auto-raise preference from the control-center and leave it as a gconf-only option: 1) It gets confused with common behavior on Windows and Mac OS X. In those environments, if a user drags something from one window to another, the target window gets raised when the user moves the mouse into that window. Users think that this is probably an enable-able preference that defaults to off in Gnome, and search for an option to turn it on. They mistake the "raise selected windows after an interval" option as doing this. 2) People mistake this option for raise-on-click. There are people who do not like windows raising upon an unmodified click in the client area (probably due to experience with other window managers that do this). They mistakenly think that this option may be related (in a sense, it is, though in the exact opposite direction--instead of turning off raising for unmodified clicks, the only thing it can do is to make things raise even sooner (when the mouse enters the window) and make it even harder to keep windows from raising). I have even seen a click-to-focus user who didn't like raise-on-click who was annoyed that "raise-on-click is only an option for mouse/sloppy focus users". Further, I find it extremely odd that this preference would be considered important enough to be in the UI even without these problems for two reasons: (1) it's used by too few people, and (2) it doesn't match the "Just Works" philosopy. In more detail: (1) The majority of people for whom I know anything about their computer usage (typically because I have to help them with computer problems) are users of sloppy or mouse focus. Not a single one of them uses autoraise. Of course, personal experience isn't proof of a wider trend (e.g. I'm certain that sloppy and mouse focus users are actually a small minority, even though that doesn't match my personal experience), but I believe that autoraise users are a small minority of sloppy/mouse focus users. Some extra reasons I believe this are: autoraise is not the default in any window manager that I'm aware of, it's the impression I get from having read through hundreds and hundreds of Metacity bugs in bugzilla, and it's also the impression I get from having googled on focus and raising bugs (I've done that once or twice for various reasons) and reading hundreds of resulting links. (2) The auto_raise option comes with a slider so that the user can determine how many milliseconds after entering a window to raise it. This slider is there because users probably want the ability to quickly move to the panel (or perhaps a window on the other side of the screen) without changing their stacking order. Of course, not all users are of equal speeds, so this delay may have to be tailored to the user which doesn't "Just Work". Anyway, there's my overly verbose reasons. I'm going to cc usability so they can say why I'm off my rocker. ;-)
Hmmm... re-reading my report my tone looks somewhat rant-ish. Sorry about that. I do think it's a confusing preference for the UI that would be better left out though.
For a couple examples of how this is confusing, see bug 139402 and bug 128664 (the comments by Zack Cerza). I had other examples as well before, but don't seem to have them anymore...
I'm wondering if we should do as Seth suggests: - add a "UNIX Users" submenu to Preferences - move the various "only people used to UNIX care" settings in there - in fact add *more* of the WM settings to the UI - in distributions, split these prefs into a separate package that is potentially not installed by default Sorry to broaden the scope of this conversation ;-) Of course, we can't call the menu UNIX since UNIX is a trademark, but we could think of something I guess.
I really hope Seth's kidding. People who "need" those settings know their way around GConf - or, they're competent enough to learn.
The split on who wants these isn't so much power users vs. regular users. It's people used to Solaris/HPUX/Irix vs. people used to Windows/Mac. An advantage is that we could not install the stuff by default and make it clear why it exists.
In this particular case I think the preference should go away. Having the preference there means we have to continue to design apps that work with "focus follows mouse". Its a design limitation that we don't need...
We can't remove focus follows mouse for now, though. That's not on the table. However, designing apps that don't work with FFM I'm fine with.
*** Bug 172137 has been marked as a duplicate of this bug. ***
"In this particular case I think the preference should go away. Having the preference there means we have to continue to design apps that work with "focus follows mouse". Its a design limitation that we don't need..." "However, designing apps that don't work with FFM I'm fine with." I think things are actually going to move in exactly the opposite direction. With a compositing window manager (& semi-transparent partially-obscuring foreground windows) sloppy focus or focus-follows-mouse will probably have to become the default. Otherwise, people will not be able to take advantage of having overlapping windows.
do we have a consensus on this? The UI freeze is soon if you want to change that for 2.12
Well, actually on d-d-l it looks like we just about have consensus to throw out the whole gnome-window-properties capplet (perhaps among others; it would be nice if Havoc and Seth or Bryan would comment on that thread)... Of course, we can remove just this preference while we wait for that, I guess. There have been no objections to the specific proposal in this report.
this part has been cleaned which fix the bug
Still there. (under capplets/window/, not capplets/wm-properties ;-)
Created attachment 57197 [details] [review] Remove the whole window menu; belongs in a separate package like gTweakUI
Currently, gnome-window-properties is enough clearly, remove this capplet is a stupid decission. gnome-window-properties only have three options: - Window selection -> The text is enough clearly "Select windows when the mouse moves over them" - Double-click titlebar to perform this action: maximize/roll-up - Movement Key ... I think that this dialog is enough clear and I vote AGAINST its removal. Thanks a lot :-)
If all you have is a standard mouse, auto-raise is insane. Things are surely different if you have a pointing device that makes the pointer leap to a chosen location. Touch screens and pen tablets qualify. Maybe add "(for touch screens)" to the dialog that enables auto-raise, and set the default delay to zero. If touch screens and pen tablets didn't exist, then sure, there wouldn't be a reason to support auto-raise. They do exist though. As for the other issue that was brought up... Ideally the default focus policy would be focus-follows-mouse. Besides being fast and efficient, this policy helps the user avoid repetitive stress injury to the fingers, hand, and wrist. The ONLY reason that click-to-focus is a tolerable default is because of the huge number of people coming from Mac/Windows, bringing their prejudices and their broken apps. The lazy-focus-follows-mouse (sloppy-focus) policy is poor. It doesn't offer a speed/efficiency/injury advantage over pure focus-follows-mouse, but it can be much more confusing for a new user. Note that correct focus-follows-mouse is just that, no more and no less. It should be impossible to get focus other than where the mouse is pointed. When using a standard mouse, it is possible (though bad style) for the system to force focus by moving the mouse. If the user has a pointing device that maps directly to the screen however, such as a digitizer pad in absolute positioning mode, then forced focus is impossible. Violating this is the main cause of user confusion.
Just to add something else into the mix, one option we (Sun) have had to provide to keep our users happy in all the versions of GNOME we've shipped is 'in sloppy focus mode, raise window on click, but only if you click on the title bar'. Needless to say it's a gconf-only option, but I'm pretty sure it's used more than "raise selected windows after interval", among our users at least. Tangential point: we talk about "selecting" windows in this dialog, but the GDSG implies that "focus" should be used for windows: <http://library.gnome.org/devel/gdp-style-guide/stable/gnome-glossary-desktop.html.en> Might be one for Shaun to add to his current "word-a-day" effort...
(In reply to comment #17) > Just to add something else into the mix, one option we (Sun) have had to > provide to keep our users happy in all the versions of GNOME we've shipped is > 'in sloppy focus mode, raise window on click, but only if you click on the > title bar'. That's not something else. ;-) I already mentioned that above as something users are confusing this option with. (And, btw, this option exists as 'raise-on-click' in gconf these days, though I should have stuck to my guns and called it by the reverse name 'orthogonal-raise'.)
But doesn't "raise-on-click" work if you click *anywhere* in the window? That's not the same thing-- the Sun option only raises the window if you click in the titlebar, otherwise it maintains its position in the stack.
(Okay, I see that the window now raises if you click on the titlebar anyway, regardless of the raise-on-click setting, so I guess the Sun option is now redundant...)
The window preferences were removed in GNOME 3.x. If they are to be re-added, it would be in the plumbing panel, not in the main UI, so not our problem any more.