GNOME and the way forward

Posted Aug 18, 2005 17:15 UTC (Thu) by newren (subscriber, #5160) [Link]

Interesting idea, but I disagree. I'm in front of my computer and if I want to use an app I will point my mouse at it.

Note that James said "two constraints people usually want honoured". See also bug 151818 comment 22 (second half of point 8 of that post), where I discussed this issue and the usage scenarios that would lead to whether users wanted new windows focused in addition to how they should be placed. Also, you seem to have ignored placement. What if the new window is big enough that it can't be placed onscreen without being placed where the pointer is? Should the window not be focused anyway? Or is it okay to focus it in that case? Should the WM attempt to avoid where the mouse is for window placement in general (that's racy if the user happens to be moving the mouse at the time the window appears...)? Should the new window be placed at the top of the stack of windows? Below the focus window in stacking (but hopefully as disjoint as possible in location)? Below all other windows to avoid races? Should it just not be shown until the user clicks on a button in the taskbar? What about apps that try to transfer focus from one of their already onscreen windows to another already onscreen window (and which may be needed in order for keynav to work correctly)--should such requests just be summarily denied because the user hasn't moved the mouse? What about alt-tab, the taskbar, and the window selector applet--should these all become no-ops and appear to be broken to the user unless the user moves the mouse at the same time? People are complaining but no one seems to be addressing all these other issues that would be needed in order to understand how to make the environment sane with a new preference.

I'm probably not the target audience though. I'm running FVWM with 16 virtual desktops in a 4x4 matrix, one app per desktop. I use MouseFocus/SloppyFocus. When I switch to a new desktop (with the shortcut keys) I expect wherever the mouse lands to be the window with focus. If it lands on the background then the focus doesn't change i.e. it's off screen.

Workspace switching behavior with existing windows isn't related to the decision about what to do with entirely new windows. It sounds like you're complaining about an old Metacity bug.

You may find this strange but it's a 100% deterministic system and I can control my focus perfectly to acheive exactly what I want. What you describe is non-deterministic because it depends on the apps doing things I can't see.

Actually, no it isn't 100% deterministic; windows can steal focus anyway. XSetInputFocus requests by apps are unconditionally granted by the XServer with the WM given no chance to prevent such focus changes (this is a bug in the X11 protocol--google for "Why X is not our ideal system" written in 1990 by some of the people who came up with the ICCCM; no, their suggestions for fixing this aren't part of X today). Granted, most apps won't do this to you but unless you've completely audited all the apps you are using (meaning the exact version of the apps that you are using), it isn't 100% deterministic.

Further, you misunderstood what James said if you think that what he wrote "depends on apps doing things I can't see". Both your method and what he outlined should be deterministic modulo bugs.

What I find most amazing is that strict-mouse-focus is the easiest system of all. Detect what the mouse is over, that window has focus. And no, clicking on it doesn't raise it either.

Why should you be amazed that an environment which you are used to is the easiest for you? ;-) Also, making the window under the mouse always be the one with focus isn't actually possible under X--see my response to Jonathan elsewhere in the comments to this article. You can get an implementation that is closer than what Metacity currently allows, but all the ones I've seen destroy keyboard navigation which doesn't make sense to me (do people really want that? Or did no one consider the possibility of inbetween behavior that gets as close as possible without destroying keynav? I could implement either but I don't know what people really want). (I discussed orthogonality of raise with other actions elsewhere in comments under this article as well so I won't repeat here)