GNOME Bugzilla – Bug 108349
Should Metacity automatically focus new windows?
Last modified: 2004-12-22 21:47:04 UTC
I don't know if this should go here, or on desktop-devel-list, but there's less chance of a flamewar here. Should Metacity automatically focus new windows? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Executive Summary: No. It should only give focus to a window when the user explicitly focuses it. Rational: 1: Windows pop up quite unexpectedly these days. Web browsers, instant messengers and other programs pop them up without any request from the user. This could lead to embarassing results: Imagine if an instant messenger window popped up while you were typing a message to someone else, insulting the person in the newly popped up window. (I know, its a slim chance). 2: It is annoying to be watching the keyboard, look up, and discover that what you typed ended up being typed into a Galeon "www.pornosite.com wants to set another cookie" window. Now it would be nice if everyone could be a touch typist, but that ain't gonna happen. 3: Principle of least surprise. Users who weren't watching the screen, like I hardly ever do whe I type, will be surprised when their text didn't get entered where they thought, and the return they hit, dismissed the window that they typed it into. (Kinda a similar rational to 1 & 2) 4: Simplifies code - You can remove 56 lines of code from window.c including two possible race conditions that you don't know how to solve (according to the comments). 5: I'm guessing this behaviour was inherited from Windows, as its been this way since I first used it at Version 3. Back in those days, programs that randomly popped up windows were rather uncommon, and the chances of the user running more than one major program where slim. Our desktops these days are rather more active and busy, with many more windows. 6: Draws users attention away from the task at hand, because if the window pops up the user has to either dismiss it, or in some way (alt-tab, or mouse movement) refocus the window they were originally working in - leads to more annoyance. I think thats all I can come up with, I hope you do change this, IMO it makes more sense to do it this way rather than the current way. If you disagree, I would like to know the rational behind it.
I love Gnome but i don't know why Havoc will not usable feature ?!?!?
This has gone back and forth a couple of times. If you search through old bugs you can probably find various discussions. The gist is that most of the time when a new window is launched, it does so by explicit action of the user, and the user will want to immediately interact with the new window. Consider for example using an xterm and launching an X applicaition -- chances are you want to interact immediately. Also true if an application is launched in response to a run_command binding. All of your examples describe cases where windows are launched through no fault of the user. This is the vast minority of windows -- almost every window is not in this category. And even windows like popup ads the user will immediately want to close anyway, through a quick Ctrl+W or mouse click.
Old discussion is at 82921 *** This bug has been marked as a duplicate of 82921 ***
The rationale is very simple: 95% of the time that a window opens, the user is intending to immediately begin using that window. Making them click it first is not a best-guess at what they want to do. Especially if they're using keynav. I would also guess that most people *do* watch the screen, and don't "typeahead" very much. IM clients and such that just open windows on their own are basically buggy/broken UI-wise; a hint "do not focus this specific window on map" that those clients could set might be a good way to address it, if they insist on opening a window. I'd like to see such a hint. Finally, since both Mac and Windows work this way it seems kind of gratuitous to deviate, and makes cross-platform apps annoying. Feel free to continue discussion on this bug rather than 82921 for thread continuity purposes, however if we reopen a bug it should be the old one not this one. Would rather not see bug 82921 reopened without significant discussion and some buy-in from UI team but I'll keep reading discussion as it occurs. At the moment I think the arguments for current behavior are very strong.
*sigh* Just one more patch I have to apply to metacity when I update it. But I'll not continue discussion, cos I don't really see the point because nothing anyone will say will change your mind.
I would love such a hint, that would solve all problems. Iain, what would not be solved by having a hint so that app authors can say that a certain window (incoming IM message or popup window in browser) shouldn't get focus?
Nothing that I can think of. It does sound like a good idea. We only have to convince aplication authors to use it. My only other worry is how long does it take to get hints added and then supported?
New hints typically get used widely as soon as we get them in GTK. So GTK 2.4 in 6 months, then the next version of each app that appears after that. This particular hint is trivial to use (one function call) so should not be hard to get people to use.
Should we also specify what type of windows should set this hint in the HIG?
The spec discussion is at: http://lists.gnome.org/archives/wm-spec-list/2003-March/msg00009.html Now leave this poor little bug alone.
For sure, should be in the HIG. (sorry Rob ;-)
How about this for a compromise: For people who use "click to focus", I think it makes sense to automatically give focus to new windows. These are the people who probably expect Windows-like behavior. These people would probably also be annoyed if they had to click on every new window that pops up. However, people who use "mouse-over focus" (that would be me) should probably not automatically give focus to new windows. I often know where the window will appear when it starts (either a blank part of the desktop if large enough, or my launcher specifies coordinates), so I will often go to an xterm on another part of the screen to continue other work. Very annoying when the focus is not following the mouse as expected. Also, if I really do want the new window to have focus, I can simply move the mouse to where it should appear, or I wait until after it appears and move the mouse to it. I was happy that you were willing to accomidate us "old-time Unix users" with a mouse-over focus preference. But if you think that was important enough to create a preference, I think this is also a reasonable change to make, and in addition it would NOT add another preference item. And indeed, it's actually more intuitive this way, since selecting "mouse-over" focus would no longer have a case where the mouse is over some other window while another window has focus.
The usuability argument applies just as well to sloppy or mouse focus as it does to click to focus. Adding special cases to certain preferences that have nothing to do with the preference is just on crack besides. But anyway the next version of the EWMH will have a new hint to allow us to determine more precisely which windows should receive focus on map and which ones should not. This I think will resolve the remaining issues of popup windows and the case where the user interacts with another window while waiting for an application to start, which are the only cases anyone has even mentioned for why windows shouldn't be focused on map. See the discussion on wm-spec-list for more information.
I think the best way to solve that issue is to do the following: When a new window appears, if the focus is on the panel (which is the case if you launch an app from the panel or from the menu), this new window takes the focus. But if the focus is on another window, the new window starts below the focused window and its task-bar entry blinks for 3 seconds. I guess that's the way Windows does it and that's a great solution IMO.
Julien - I already tried to implement the windows policy as you describe, that was the original metacity policy. It doesn't work on unix, primarily because many apps don't properly mark the transient parents of dialogs, so dialogs don't get focused, IIRC. If you go back through bugzilla/ChangeLog you can find discussion of this and why we reverted it. Also read recent wm-spec-list threads on this topic.