GNOME Bugzilla – Bug 122577
Using sloppy focus, windows do not raise on click
Last modified: 2004-12-22 21:47:04 UTC
Description of Problem: Using sloppy focus mode, if you click inside a window which is on the bottom of the desktop (aka. there is one or more windows in front but you can still see a part of this window) the window won't raise on top unless you click on the border of this window. Steps to reproduce the problem: 1. preliminary you have to select sloppy focus mode without a limit time for automatically raising windows on top 2. open 2 windows (one partialy covering the other) 3. move the mouse over the bottom windows so it gets the focus 4. click inside this windows in order to raise it on top of the desktop Actual Results: the window doesn't raise Expected Results: the window raises How often does this happen? every times I try Additional Information: I find other users having the same problem.
using gnome 2.4 and metacity 2.6.1 from Dropline Gnome distribution for Slackware 9 ( http://www.dropline.net/gnome/ )
Theoretically this was done intentionally, though not for clearly-defined reasons. We need a discussion of how we really want to address this issue.
I can confirm this for current Gentoo (Metacity 2.6.1). It's a pain, and unfortunately some are mistaking this for a new Gnome 2.4 feature and being discouraged ... (It's not a feature, right? Please say no ... windows damn well should be raised when clicked ...)
It's a combination of a feature and the fact that a fix for another bug made it sort of happen without really thinking about it. The theory is that sloppy and mouse focus becomes sort of a "historic" x interface while click-to-focus becomes a more modern click-to-raise-and-focus interface. A number of users had been requesting a raise-on-click preference; this is something of a compromise. What we need here however are solid, well-thought-out justifications for why we think the UI should be a certain way, and then make it that way.
First not being able to raise a window by clicking inside is not consistent with the fact that it is possible to raise it anyway by clincking on the window decoration. A choice has to be made : is it possible to raise a window with a click in sloppy mode or not ? (rather specious argument, isn't it ?) To give the user the possibility to distinguish focusing and raising is a unique feature, which I had some uses*. I found it more interesting than a variable delay before automatic raising which appears more cosmetic to me (fixing a delay equivalent to the time needed to click in a window should be enough). It give more flexibility to the "historical" focusing mode. Never forget the past but use it to build the future ;) (such a sentence could have been extracted from fortune :D) * a few examples : -typing commands in a term while seeing the resulting log in another one whitout having to resize the windows everytime. -watching a video while surfing with a browser. feel free to complete theses few ideas
ccing usability
OK guys, we've had this discussion AT LEAST 400 times. At least I have. ;-) There's more than one closed bug with huge verbage on it, should be added to rationales.txt. One of those has a lot of explanation of how you could make things just work (raise normally, but not when it would be useful to not raise). That's the only solution I'm really interested in. I'd take a patch to go back to raising always if someone wants to write it, because I think it's marginally better and is at least how it used to work. Basically you have to do an async grab instead of the old sync grab (a grab that passes through the click immediately) to change this back without breaking mozilla again. See the old bug about that, should probably also be in rationales.txt. The other patch I'm interested in is one that then avoids the raise in specific cases, such as DND or when selecting text. I don't want any comments other than these two patches and questions about how to implement them, really. Comments will just keep people from seeing this comment about the patches they need to write. And that will keep the patches from being written. If you _must_ discuss the merits of whether to always raise or always not raise in mouse focus modes (when the always-do-anything is clearly broken, and mouse focus is clearly broken), please discuss that on desktop-devel-list@gnome.org or usability@, not on bugzilla.
Should this be marked as a duplicate of 115072?
uuhhh, sure. *** This bug has been marked as a duplicate of 115072 ***