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 152004 - "Strict pointer mode" (whether to focus on map--see comments 7 & 14)
"Strict pointer mode" (whether to focus on map--see comments 7 & 14)
Status: RESOLVED DUPLICATE of bug 326159
Product: metacity
Classification: Other
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
: 160589 161275 321759 (view as bug list)
Depends on:
Blocks: 155450 155460
 
 
Reported: 2004-09-06 18:29 UTC by Havoc Pennington
Modified: 2006-04-12 18:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch for "strict pointer mode" (12.27 KB, patch)
2004-09-06 18:30 UTC, Havoc Pennington
needs-work Details | Review
How to get focus right--all our current policies (text file) (5.94 KB, text/plain)
2004-09-06 22:13 UTC, Elijah Newren
  Details
Modifications to the how-to-get-focus-right file (9.32 KB, text/plain)
2004-09-07 21:06 UTC, Elijah Newren
  Details

Description Havoc Pennington 2004-09-06 18:29:02 UTC
This patch adds "strict pointer mode" which sledgehammer turns off all keynav
heuristics, including focusing new windows, focusing default windows, etc.
It is driven by customers who are used to mwm/4dwm and use legacy apps that
don't have keynav anyhow and have zillions of little windows. The original
request was for a bunch of individual settings (don't focus on map, do
such-and-such on workspace switch, etc. etc.) and I collapsed it all into a
single "mode"

This patch is just to show the idea, it's not fully baked (it's vs. 2.4.55, I
thought I had it vs. HEAD also but don't see it right now)
Comment 1 Havoc Pennington 2004-09-06 18:30:29 UTC
Created attachment 31338 [details] [review]
patch for "strict pointer mode"
Comment 2 Elijah Newren 2004-09-06 18:53:02 UTC
/me breathes a sigh of relief to learn that this is a different mode rather than
a modification of the existing mouse and sloppy focus modes

However, it seems kind of odd for two reasons: (1) I believe the patch in bug
135810 (already committed) combined with an option to have windows default to
not focusing on map would already cover every change this patch makes; (2) I
believe this patch would fall short of being a strict pointer mode because of
the change in bug 110970 (i.e. bug 124798/bug 123803 would affect this strict
pointer mode).
Comment 3 Elijah Newren 2004-09-06 19:17:50 UTC
Doh, I fired off way too quick.  Let me modify my above statements:

(1) Actually there are more issues: (A) The patch in bug 152000 would also be
needed to make strict pointer mode work.  (B) The patch in bug 135810 combined
with a don't-focus-on-map-by-default option may actually work better than the
strict-pointer-mode in one case--if the user is using sloppy focus and closes a
window and there is no window beneath the pointer, one would expect the mru
window to get focus (similar to a workspace switch; see bug 135810).  The
strict-pointer-mode doesn't do that and may (I haven't checked closely) suffer
from a "keyboard-lock" problem similar to the one in bug 147475 (due to lack of
any window having focus).  (C) focus-stealing-prevention makes not focusing on
map a little weird since the DEMANDS_ATTENTION hint is set and the window is
lowered in those cases.  So the patch may have to do something about that. 
However, focus-stealing-prevention itself /might/ be a "good enough" fix that
would remove the need to not-focus-on-map-unless-the-mouse-is-there.  (Note the
emphasis on might, I'm sure you'll still get customers requesting it, if they
really do want a strict pointer mode)

(2) Note that the patch in bug 110970 was committed as part of the 2.5.x series
of Metacity, which is why no one would have noticed bug 124798/bug 123803 when
using that strict pointer mode on rhel3.
Comment 4 Havoc Pennington 2004-09-06 20:23:52 UTC
Watching how many problems we have with the existing 3 focus modes, adding an
additional two via this patch does seem a little worrisome. If we could change
it to only a "whether to focus on map" then OK, but my worry is having to go
back and add a zillion settings like "don't focus the mru window when closing a
dialog", "don't focus mru window on workspace switch", etc. etc. so need to go
through all those and get a sense.

This patch is indeed known to cause "keyboard shortcuts stop working" problems,
though I was hoping this fix would avoid that:

2003-09-26  Havoc Pennington  <hp@redhat.com>

	* src/display.c (event_callback): when focus on root window
	becomes None, set it to something other than None so keybindings
	keep working and print a warning about how some application sucks.
	#84564
	(event_callback): Fix debug spew to print focus event details
	properly
	(meta_display_open): when setting initial focus, always use
	RevertToPointerRoot and fix the focus if it's None or PointerRoot

I think that fix wasn't in 2.4.55...

Wow, once all this focus crap is fixed it feels like we need a freaking
whitepaper on how it all works and why and what the alternatives were so we 
can properly evaluate future proposed bugs and changes... I'm really confused 
by now.
Comment 5 Elijah Newren 2004-09-06 22:12:15 UTC
You don't need to worry about cases like "don't focus the mru window when
closing a dialog" and "don't focus mru window on workspace switch".  The reason
you don't need to worry about them is the logic added in bug 135810.  For sloppy
and mouse focus, when a focused window becomes invalid, we specified that the
new focus window should be:
   sloppy - focus the window containing the pointer if there is one, otherwise
            focus the mru window
   mouse  - focus the window containing the pointer if there is one, otherwise
            focus the no_focus_window
(Well, okay the no_focus_window part was added in bug 147475 because we can't
just not focus any window--bug 147475 showed that there is at least one case
when the catch-no-window-is-focused patch isn't quite sufficient)  In other
words, the window where the mouse is takes precedence--just as
strict-pointer-mode would require.  (Letting them take precedence also avoids
race conditions, such as those found in bug 131582).

I think your request for a "whitepaper" that explains everything would be
helpful as well.  So I'll attach one in a minute.  I'm a little unsure about the
"modal vs. non-modal newly mapped window which is denied focus" both because no
one has commented on bug 151996 yet and because there may be other related cases
that I have missed.
Comment 6 Elijah Newren 2004-09-06 22:13:31 UTC
Created attachment 31342 [details]
How to get focus right--all our current policies (text file)
Comment 7 Havoc Pennington 2004-09-07 04:11:00 UTC
I see, I think I somehow missed the big picture that we've cut over to always
using strict pointer rules with sloppy/mouse focus on HEAD, with the exception of 
focusing new windows on map (or not). So nice, we can probably just skip this
patch entirely.

I'd say we shouldn't add a "focus on map" setting until we get the focus
stealing prevention fully working and see how good it is.

Thanks for the writeup, suggest adding it to doc/ and mention its existence in
rationales.txt (maybe replace the mention of focus bugs with a pointer to this 
document)

Comment 8 Elijah Newren 2004-09-07 21:06:45 UTC
Created attachment 31394 [details]
Modifications to the how-to-get-focus-right file

Okay, I'll add it to docs and update rationales.txt.  I noticed some things
that I thought would be useful to add to the writeup, so I've attached a patch
regarding what I've changed in it.  In summary:

1) We treat WM_DOCK and WM_DESKTOP windows differently (they are only focused
on explicit click, and are effectively shuffled to the end of the list when
considering a new window to focus), yet the writeup didn't reflect that.

2) There are invariants we are trying to maintain for each focus mode, but I
didn't make that explicit before.  I think doing that makes things clearer, and
also motivates the choice for the new window to focus when the previous one
goes away.

3) I thought it would be nice to have a write-up on the difficulties that come
with sloppy and mouse focus methods so that we can point users to it if
necessary.

Anyway, holler if you see something that needs to be changed or something else
I should add.  I'm going to commit it to cvs in a minute.
Comment 9 Havoc Pennington 2004-09-07 22:14:25 UTC
Comment on attachment 31394 [details]
Modifications to the how-to-get-focus-right file

Looks nice, one other thing to mention is that you can focus panels/desktop
with Ctrl+Alt+Tab, otherwise we'd have no way to keynav those.
Comment 10 Elijah Newren 2004-09-07 22:33:29 UTC
Right, I forgot about that.  I updated it in cvs.
Comment 11 Elijah Newren 2004-09-28 21:37:14 UTC
Comment on attachment 31338 [details] [review]
patch for "strict pointer mode"

Since this doesn't apply against HEAD, I'm going to mark it as needs-work in
order to get it off the patch-diligence report
(http://bugzilla.gnome.org/reports/patch-diligence-report.cgi)
Comment 12 Elijah Newren 2004-12-06 16:41:12 UTC
*** Bug 160589 has been marked as a duplicate of this bug. ***
Comment 13 Elijah Newren 2004-12-14 16:21:54 UTC
*** Bug 161275 has been marked as a duplicate of this bug. ***
Comment 14 Elijah Newren 2005-02-02 17:26:08 UTC
Wahoo!  Russell Nelson (nelson crynwr com) suggested an alternative via email
that would remove the need for any preference for focus-on-map by adjusting the
placement algorithm appropriately:

 - when a new window should take focus on map, it gets positioned so that it
   is underneath the mouse.
 - when a new window should not take focus on map, it's placed so that it's
   NOT underneath the mouse.

This is worth investigating to determine whether this can be part of a sane
window placement algorithm.  If so, this would be ideal because we'd get a "Just
Works" environment with one less preference to muck things up.
Comment 15 LaMont Jones 2005-02-02 18:08:44 UTC
> - when a new window should take focus on map, it gets positioned so that it is
underneath the mouse.

That presumes that it knows it should ttake focus on map.  My brain is still
wrapped around launching several windows from one (with thought time), and not
having focus leave the window I'm in.  That is, in xterm #1, launch 3 more
xterms one at a time.  Needing to refocus on xterm #1 between each one causes me
pain.

There is no way for metacity to know that I want it to do that, hence the need
for a sledgehammer switch
Comment 16 Elijah Newren 2005-02-02 18:25:12 UTC
LaMont:

> There is no way for metacity to know that I want it to do that

That's mainly because applications launched from a terminal aren't launched with
startup-notification.  There is a way to fix this to work without
startup-notification (Soeren's suggestion--see bug 151984) which would make it
so that as long as you are using a terminal that supports _NET_WM_USER_TIME and
you keep typing before the window appears, then Metacity will know that you
don't want the launched window to be focused.

Note, however, that your entire scenario is a niche usage case restricted to
launching applications from a terminal, whereas everything else in this bug is
for more general usage cases.  I'm not trying to say launching apps from a
terminal is an unimportant case (because I am one of those niche users and I do
feel your pain), it's just that we have to focus on getting other things right
first.  Besides, I believe there's a way to fix even this niche case without an
ugly suboptimal sledgehammer switch.
Comment 17 nelson 2005-02-02 20:37:41 UTC
LaMont:

The best way to launch four xterms when you're using sloppy focus is by running
". xterms" and creating a shell script that looks like this:

#!/bin/sh

xterm&
xterm&
xterm&
xterm&
Comment 18 Kjetil Torgrim Homme 2006-01-08 03:59:43 UTC
Your write-up says "Most users want to interact with new windows right away, so these should typically be focused.", but it seems to me that the rest of the document presumes ALL users.  Or perhaps not.  In any case, let me add a vote for a "strict" mode.

If I'm in a window, and a new window pops up, but not under my pointer, I certainly don't want my focus to be stolen away.  To get the focus back, I have to move the pointer OUT then BACK again.  This is very inconvenient, and very unnatural behaviour for the "mouse" focus_mode, IMHO.  The only case where I personally will accept focus moving to a different window without my explicit consent, is where the currently focused application throws up a transient window (a Find dialog or similar).

I guess I should add I'm just trying to switch to GNOME after having run the succession of rwm/twm/fvwm since 1990.  This is really the only sticky point left.
Comment 19 Elijah Newren 2006-01-09 15:19:23 UTC
(In reply to comment #18)
> To get the focus back, I have to move the pointer OUT then BACK again.

Actually, there are other ways to get focus back -- one of them being that you can also click on the window (which is also useful for cases like when you use alt-tab to switch focus to a window that isn't under the mouse, work with it for a while, then decide to start using the mouse and the window under it without alt-tabbing back).
Comment 20 Kjetil Torgrim Homme 2006-01-09 15:42:00 UTC
Sure, but I'd have to move my hand to use the mouse, and that click is passed through to the application, so it's not a no-op.  (e.g., in XTerm it will blank the selection.)

Of course, Alt+Tab works, too, if you have it bound to switch_windows.  But that means I have to be aware of the loss of focus, and actively perform an action (at the right time!) to undo the focus loss which I didn't want to happen in the first place.  Getting the timing right is not easy either.  When I'm typing along, it happens quite often that I finish the command just as the new window appears, so it receives the tail end of the command _and_ the Return.  Which causes the new window to quickly disappear, unread, if it was an informational popup.
Comment 21 Elijah Newren 2006-04-12 18:08:28 UTC
In metacity 2.15.x:
  gconftool-2 --set /apps/metacity/general/focus_new_windows --type string strict


*** This bug has been marked as a duplicate of 326159 ***
Comment 22 Elijah Newren 2006-04-12 18:11:02 UTC
*** Bug 321759 has been marked as a duplicate of this bug. ***
Comment 23 Kjetil Torgrim Homme 2006-04-12 18:59:01 UTC
I object to marking this as a duplicate of bug 321759.  this does not only apply when my focus happens to be in a terminal, windows can pop up randomly for many reasons.  why would I want my focus behaviour to be different depending on what I point at?  I want consistent behaviour, and the simplest way to get that is to let "strict" mean "strict".