After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 89981 - in point-to-focus mode, new windows should get focus (like they do in click-to-focus)
in point-to-focus mode, new windows should get focus (like they do in click-t...
Status: RESOLVED FIXED
Product: metacity
Classification: Other
Component: general
unspecified
Other other
: Normal major
: GNOME2.x
Assigned To: Metacity maintainers list
Metacity maintainers list
: 93753 96994 97787 99207 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-08-06 04:53 UTC by Alex Duggan
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
focus new windows even in sloppy focus mode (993 bytes, patch)
2003-01-04 23:51 UTC, Rob Adams
none Details | Review

Description Alex Duggan 2002-08-06 04:53:48 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.
Comment 1 Tuomas Kuosmanen 2002-08-06 04:59:56 UTC
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.
Comment 2 Luis Villa 2002-08-07 18:31:40 UTC
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 :) 
Comment 3 Alex Duggan 2002-08-07 18:36:01 UTC
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.
Comment 4 Luis Villa 2002-08-07 18:46:39 UTC
I'm retitling- is that more accurate? hp- looks like you only fixed
82921 for click-to-focus and not point-to-focus mode.
Comment 5 Tuomas Kuosmanen 2002-08-08 06:20:39 UTC
Yeah, this title says it better :) Click to focus works correctly, the
problem happens with the mouse focus mode.
Comment 6 Havoc Pennington 2002-08-10 14:50:43 UTC
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().
Comment 7 Tuomas Kuosmanen 2002-08-10 23:26:19 UTC
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?
Comment 8 Havoc Pennington 2002-08-11 02:47:07 UTC
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. ;-)
Comment 9 Havoc Pennington 2002-09-20 12:50:49 UTC
*** Bug 93753 has been marked as a duplicate of this bug. ***
Comment 10 Rodney Dawes 2002-09-22 13:07:43 UTC
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.
Comment 11 Havoc Pennington 2002-09-22 14:51:13 UTC
It isn't intended to be fixed, the bug is still open...
Comment 12 Havoc Pennington 2002-10-28 05:01:08 UTC
*** Bug 96994 has been marked as a duplicate of this bug. ***
Comment 13 Heath Harrelson 2002-11-07 11:11:40 UTC
*** Bug 97787 has been marked as a duplicate of this bug. ***
Comment 14 Heath Harrelson 2002-11-21 23:12:48 UTC
*** Bug 99207 has been marked as a duplicate of this bug. ***
Comment 15 Rob Adams 2003-01-04 23:51:46 UTC
Created attachment 13354 [details] [review]
focus new windows even in sloppy focus mode
Comment 16 Rob Adams 2003-01-04 23:56:08 UTC
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
Comment 17 Havoc Pennington 2003-01-05 00:15:27 UTC
Patch is fine to apply with ChangeLog, thanks.

(should use "-u" option to diff, much easier to read)
Comment 18 Rob Adams 2003-01-05 18:14:34 UTC
Sorry did you mean you wanted me to commit it?  I don't have commit
access...
Comment 19 Havoc Pennington 2003-01-05 18:39:02 UTC
OK, I put in the change, thanks.
Comment 20 Håkon Innerdal 2003-02-10 11:31:44 UTC
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!