GNOME and the way forward

Posted Aug 18, 2005 6:35 UTC (Thu) by sfeam (subscriber, #2841) [Link]

Posted Aug 18, 2005 8:30 UTC (Thu) by spitzak (subscriber, #4593) [Link]

Posted Aug 18, 2005 15:56 UTC (Thu) by tjc (subscriber, #137) [Link]

This behavior is fairly close to Windows XP, so I don't think it would confuse "normal" users.

If one starts a program in Windows XP and then gives the focus to an existing window (by clicking on it) before the new window is mapped, the new window is placed in the stacking order just below the focused window, and the current window retains focus. This seems to work well enough that most people don't even realize that it's happening.

Extending this to focus-follows-pointer mode, it seems reasonable to assume that if a user chooses focus-follows-pointer that they are not likely to be confused by windows retaining focus no matter what. Mapping the new window second-from-the-top is nice too, since mapping a "dead" window over the top of the currently focused window is almost as bad as stealing focus.

Posted Aug 18, 2005 23:03 UTC (Thu) by zblaxell (subscriber, #26385) [Link]

Now, some people have requested a window-is-focused-iff-pointer-is-in-it (which destroys/prevents keyboard navigation

focus-the-new-window-only-if-it-happens-to-appear-where-the-mouse-pointer-is. I don't quite understand why people would want this or if people really do; I'm of the opinion that those who wanted this were probably just really annoyed by all the dozens and dozens of bugs that used to exist...am I mistaken?

Most of the bugs you refer to arise in the first place when people try to do something complicated with lots of inputs and heuristics, and in my experience the best possible outcome of "intelligent" focus management is something that behaves inconsistently in some cases, provides no benefit over pure focus-strictly-under-mouse, but has failure modes that are only relatively obscure or harmless. Most people who even try do much worse. The annoying thing to me is that so many people seem to consider this to be some kind of problem to solve, when it's not. Just put the focus where the mouse is. Done.

I attest that I've tried both focus-under-mouse and focus-strictly-under-mouse modes or their equivalents on at least half a dozen window managers, and I can tell the difference in practice, and much prefer focus-strictly-under-mouse, and use support or lack thereof for this mode as a discriminating factor when choosing a new window manager. You'd sooner convert an nvi user to vim. ;-)

Where the mouse pointer is, so shall the focus be; conversely, where I want the focus to be, I must move the mouse pointer to. Put another way, all of the right, and all of the responsibility, to decide where input goes, is in my mouse hand. Doing it any other way generally feels like a 2-year-old has plugged a mouse into the USB port on the back of the machine and is now teething on it. If I have to use a desktop configured for "raise on click" combined with "click to focus," I generally refrain from using multiple windows at all, since I can't always organize them as I would like with those management primitives. At the opposite extreme is "autoraise", which I can't use at all.

I have access to information that the window manager could not possibly have. I know in advance where an application is going to appear in a few seconds from now, since I launched it--possibly from a different machine--and I know it's preconfigured to appear there, and I also know if I'm launching a single application or the first of six.

Sometimes (especially on laptops) my mouse cursor strays into "inter-window space", and it's better for input to fail immediately (and preferably noisily), than to continue to work until the cursor strays a little further into "incorrect-window space," where it can do serious damage (imagine typing this sentence into vi...now imagine typing it into a live database application where most changes are immediate, globally distributed, and permanent). This is why sloppy focus is not sufficient--the slop generally manifests itself in apparently random applications getting focus when the mouse cursor is on the root window.

New windows that pop up under where the mouse cursor happens to be are a problem; however, the usual "focus stealing" algorithm is a complex, inelegant, race-prone non-solution. A better idea is something like ratpoison's "rudeness" bits, which apply a filter on which windows can display themselves or raise themselves in the stacking order. Generally if I want to prevent windows from opening at all, it's because I'm doing a specific task that I don't want interrupted, so it would be enough to have a WM command for "allow no windows to be raised until further notice."

With xterm I can lock the keyboard focus on the current application until a magic event is triggered to release the focus lock (the "secure keyboard" mode). It is possible to interact with, even click on other applications in this mode, but keyboard input is unconditionally directed to the xterm. This is really handy and I use it quite often, especially with applications like wish or mplayer which simultaneously use TTY and X11 interfaces. It would be nice if the WM could do this consistently across most applications, so that every application doesn't need to implement the feature. Nothing other than the specific "release focus" command would release the focus from that window once it was locked--not even if the locked window goes away.

The opposite (windows that can't get focus until a specific keybinding or window menu entry is fired) could be useful too: I've often had an xchat window get the focus unexpectedly (e.g. the mouse drifted, or the window obscuring xchat disappeared and the mouse ended up in xchat) and wished that it hadn't received the last few lines of typing. I would be willing--in fact, I'd prefer--to invoke a window manager command each and every time I wanted to enable input on xchat after switching from another window.