GNOME Bugzilla – Bug 89981
in point-to-focus mode, new windows should get focus (like they do in click-to-focus)
Last modified: 2004-12-22 21:47:04 UTC
All new windows should receive mousefocus when they are first created. For example, when a mozilla window is focused and the user presses control-n, the new windows that is created should get the mouse focus, no matter where the mouse cursor is.
Oops, think I caused a bit of confusion here when talking with Alex about this. So the mousefocus thing means "this works correctly with click to focus mode, but breaks if you use mouse focus". Although mozilla dialogs *do* get focus when they appear, while GNOME apps (and most other things) dont. So read the above with s/mouse.focus/focus/g I definitely think all new windows should get focus when they appear.
How recent is your metacity, guys? hp indicates he fixed most of this some time ago (bug 82921.) So- what's left? Exactly what things aren't getting focus under what conditions? You'll admit the bug report is a little vague about that :)
I'm using cvs HEAD and I update every few days. The example that bothers me most is when I click a launcher on the panel and the resulting program that launches does not have to focus. This is extremely annoying when launching a gnome-terminal. It is also annoying when using a web browser and opening a new window that that window does not have focus.
I'm retitling- is that more accurate? hp- looks like you only fixed 82921 for click-to-focus and not point-to-focus mode.
Yeah, this title says it better :) Click to focus works correctly, the problem happens with the mouse focus mode.
Oh, now that I look at the code apparently I did this on purpose. The idea being to maintain the invariant that the window the mouse is inside is focused, as you may focus a bunch of random crap en route to the new window anyway, I guess. Obviously I don't feel super-strongly about it since I forgot I did it this way, but it made sense at the time... to fix this we just remove the conditional on focus mode in meta_window_show().
Yeah, the idea makes sense. But it is pretty useful when you focus new windows automatically, since in most cases those are dialogs (save as, etc) that you just type a filename in and press enter - thus no need for mouse interaction. Would it make sense if you keep the new window focused unless you got a mouse movement?
Yeah, it probably still makes sense to focus new stuff since it helps with keynav. Since I started using click-to-focus I never know what's right for sloppy anymore. ;-)
*** Bug 93753 has been marked as a duplicate of this bug. ***
It's not fixed in 2.4.1 for click-to-focus. I still have many apps which don't get focus on window creation. X-Chat 1.8.9 being one of them.
It isn't intended to be fixed, the bug is still open...
*** Bug 96994 has been marked as a duplicate of this bug. ***
*** Bug 97787 has been marked as a duplicate of this bug. ***
*** Bug 99207 has been marked as a duplicate of this bug. ***
Created attachment 13354 [details] [review] focus new windows even in sloppy focus mode
Think about this from a user perspective for a moment. You're working on something, and you initiate an action that causes a new window to be created. Are you more likely to want to work in that window right away, or are you more likely to want to do something else first? I would put forth that you're more likely to want to deal with the new window immediately. I find myself alt-tabbing a lot to get to new windows that I launch from an xterm or from somewhere else. Really, the only exception I can think of are pop-up ads in browsers, and even then you probably want to get rid of it right away. Also, if you're launching numerous windows from an xterm before working with them, you might like the other way better, but in this case I would imagine that users will want to position each window where they want it before launching another window. Attached patch does exactly as Havoc suggests and removes the conditional. I find it to be much nicer. -Rob
Patch is fine to apply with ChangeLog, thanks. (should use "-u" option to diff, much easier to read)
Sorry did you mean you wanted me to commit it? I don't have commit access...
OK, I put in the change, thanks.
Regarding the "new window autofocus" functionality recently introduced in metacity, I really hope that there are plans for making this configurable, I love the simplicity of metacity, and untill now, behaving just excactly how a good WM should, but I'm not used of this autofocus thingy, and this is _the_ most disturbing functionality that M$ Windows has implemented that prevents me from using that OS as a production environment. I know, pleasing everyone is not really easy, and I can understand those that want this functionality, so I hope this newly introduced feature can be made configurable, to please both groups of users. Personally, I've reverted the functionality in the code, thank god for opensource, but pretty please, make this configurable! Sadly, I haven't enough knowledge of gtk/gnome to provide a complete patch for this, so I hope you gurus can do this. The reason for not wanting this feature, is that several applications pops up dialogs now and then, withouth the user have requested them, (e.g. new ICQ message, warnings, errors etc...), and I cannot think of anything more disturbing sitting typing some code, sudently a popup steals the focus, and the keyboard focus is streamed to /dev/null except the cr/lf which effectively closes the popup with default action before the poor user know what was the reason for the popup. Additionally, those that multitask a bit, and is used to application startup delay, often forks up a dialog based program with & (or ctlr-z, bg) continuing to work in the shell, and is not willing to give up the keyboard focus at the excact moment the forked app window is displayed (a heavy IDE needs additional time to load modules (e.g. Sun One) and loosing keyboard focus each time a status -window is popping up is pretty anoying, blame it on the application, ok, but at least make this behaviour configurable through gconf, for those of us that is used to the old unix way to do things.... keep up the good work!