Posted Aug 18, 2005 16:17 UTC (Thu) by newren
In reply to: Focus stealing
Parent article: GNOME and the way forward
Rather than using elaborate schemes involving race conditions between the user and new applications, why not just have the focus be on the window under the pointer, always?
Maybe because (a) that's not actually possible in X (though yes, we could get much closer), (b) it also suffers from race conditions the way you've described it, (c) it inherently causes breakage with various other parts of the UI, (d) there's not always a window under the mouse (okay, so I'm being picky--we do have both sloppy and mouse focus modes after all for users that have different preferences in this situation), (e) some windows shouldn't get focus ever even if the mouse is over them, and (f) it is counter-intuitive for most users?
A little more explanation for those points that might not be obvious:
a) Applications can grab the mouse so that the WM isn't notified of mouse entry/exit from windows. Open up a menu in some app, move the mouse to another app--note that the window with the menu open still has the focus. Fixing would require re-writing all applications.
b) Imagine this: User starts an application, while waiting they go to interact with some other app and clicks around on it, the launched application window happens to appear and covers the window(s) the user was working with (or do you expect new windows to be placed at the very bottom of the stack of windows?), and then the user clicks before they realize that a new window has appeared and thus initiates some action they didn't want.
c) Your suggestion breaks the taskbar ("window list applet"), the window selector applet, alt-tab, and all applications that try to transfer focus from one of their windows to another. Effectively, it's impossible to do keyboard navigation.
f) I understand that among those that use terminals heavily, there are many that like to launch applications in the background and continue working. But most users launch an application and then want to use it; defaulting to not focusing new windows just doesn't make sense.
It is possible that a preference could be added (and one was proposed before by Havoc under the name "strict pointer mode", which I've talked about elsewhere in the comments here and the problems with understanding it), but I really need to know what it means. The comments in this article are helping, but if you read through it you'll probably find why it's hard to figure out what people really want (you described it first as "don't have windows take away focus while I'm busy with some app" which we can mostly get assuming apps are launched with startup-notification; now you describe it as focus-on-window-under-mouse-always which isn't quite possible and might entail more than you mean (do you really want keynav and window applets to be totally broken and to break apps that shouldn't take focus and to make an effort to rewrite all apps? or do you just want new windows to not be given focus? what about window placement and stacking for such new windows?); someone else tried to describe it in terms of what should happen when switching workspaces (probably alluding to an old Metacity bug) which is unrelated to new windows appearing.
image two emacs windows both of which are over a firefox window. Move the pointer from one emacs to the other, crossing over a small strip of the buried firefox window, and the focus may well end up on firefox.
This sounds like something that trying to have the WM enforce window with pointer has the focus may not fix; it's most likely some other deeper bug. I'd love to see a verbose debugging log:
- Reduce your desktop to as few windows as possible to reproduce the bug
- Run METACITY_VERBOSE=1 METACITY_USE_LOGFILE=1 metacity --replace
- On stdout metacity will print the name of the logfile
- Reproduce the bug as quickly as possible
- Kill the metacity you started above to stop the logfile from growing any longer
- Send me the logfile
to post comments)