Focus stealing

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

In KDE with focus-follows-mouse - you can give a delay - so if you jump past a window (like firefox) the focus is not taken - as long as it is within that configurable delay.

Also works for focus-under-mouse and focus-strictly-under-mouse modes, right? Kind of defeats what he requested, though ("why not just have the focus be on the window under the pointer, always?").

Also - if I in konsole start xclock - and the mouse stays over the konsole - xclock does not get focus, simply because it started.

KWin has four focus modes, IIRC. Which of them are you using (please check closely as three of them have very similar names)? Also, again IIRC, KWin's level of focus stealing prevention is configurable to 5 levels. To which level have you set it? (If I were to take a guess, I'd say you're using the default level of focus-stealing-prevention and using either the "Focus under mouse" or "Focus strictly under mouse" modes which totally destroy keynav (as claimed by KWin itself). I think adding a "strict" mode to metacity that doesn't focus new windows might make sense but I'd make it somewhat different as I don't think keynav should be ruined in any focus mode)

Secondly, note that you can use KWin under Gnome and Metacity under KDE. People have done both. I just point this out because technically you should have said "KWin" instead of "KDE" in your post, though it's unlikely you caused any confusion. ;-)

Posted Aug 18, 2005 16:36 UTC (Thu) by tjc (guest, #137) [Link]

> But most users launch an application and then want to use it; defaulting to not focusing new windows just doesn't make sense.

You missed a step.

1. Launch application.
2. Drink coffee or pop for 10 seconds while you wait for all the shared libraries to load.
3. Use application.

Skipping step 2 results in a lot of frustration, which leads to criticism. Maybe this problem is more acute than it used to be, now that software takes so long to load. If no-one has the will to address the 10-second load time, then maybe the UI needs to be altered to accomodate it.

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

While you raise some valid points, I think some of the problems you mentioned have already been solved by non-GNOME projects.

a) Applications can grab the mouse so that the WM isn't notified of mouse entry/exit from windows. Open up a menu in some app, move the mouse to another app--note that the window with the menu open still has the focus. Fixing would require re-writing all applications.

I routinely hit Ctrl-Alt-Divide on the keypad to break these, e.g. when I've popped up 2 levels of menu, then realized I have to go visit some other application to get information required to make a decision. It's usually worth the finger gymnastics on the keyboard to avoid having to describe the curvy path to the Nth level deep menu with a touchpad twice.

The applications don't seem to mind, and I didn't have to rewrite them, I just dishonor their input grab requests from the X server. In fact, I often wonder why it ever seemed necessary to grab the mouse or keyboard focus for these operations in the first place, since the menus work just fine without it, and modifying any particular application or toolkit to work that way is trivial. There are really good reasons to not grab the mouse and keyboard--especially if the application is prone to locking up while it has a menu posted.

b) Imagine this: User starts an application, while waiting they go to interact with some other app and clicks around on it, the launched application window happens to appear and covers the window(s) the user was working with (or do you expect new windows to be placed at the very bottom of the stack of windows?), and then the user clicks before they realize that a new window has appeared and thus initiates some action they didn't want.

Ratpoison has permission bits on raise and display requests that users can grant or revoke at will, with different policies for transients and non-transients. Control over these bits is considered a normal window management operation: users can have key bindings to switch windows, resize windows, and set "rudeness" bits as they like--it's not buried under four levels of user menus and dialogs, it's something that might change as the user switches from one application to another, depending on the user's current task. The feature is also exactly where it belongs--in the window manager, not the application. The effect is nice--no matter how obnoxious your mail client or web browser is, it can't interrupt your work by popping up a window on top of what you're doing, until you explicitly permit it.

In the GNOME or KDE context, there could be a little button in the taskbar, like the keyboard language indicator, which a user can click on when they don't want to be bothered by new windows for a while. It might even be reasonable to provide a mode where new windows appear on the bottom of the stack instead of the top, although if it was technically feasible, I'd try to get the new window to be immediately below the window with the mouse cursor, and first in the Alt-Tab list. Forcing all new windows to be minimized would work too, although I wouldn't be surprised if there was at least one application that would just try to un-minimize itself.

c) Your suggestion breaks the taskbar ("window list applet"), the window selector applet, alt-tab, and all applications that try to transfer focus from one of their windows to another. Effectively, it's impossible to do keyboard navigation.

twm never seemed to have a problem with this. twm did have rules about warping the mouse cursor--if you used keynav to select windows in twm, the mouse cursor moves at the same time. That was annoying, but from a user's point of view, it didn't break the "focus strictly under the mouse" rule, and I'll take annoyingly consistent over consistently annoying any day.

Another quirk is that pointing at the "icon list" in twm (the closest thing to a taskbar) put the keyboard focus on the corresponding application window. I could hit Ctrl-Q repeatedly while panning over the task list with the mouse to get rid of a lot of windows of some application or other. Unlike the usual "Close all" popup menu, I could send any keyboard command to the applications.

Digression: I wish more window managers would implement alt-Tab the way sawfish used to: as you alt-tab through the windows, it pops up each window to the top--and if you keep going, it pops the window back to its original place in the stacking order. This is really handy if there are 20 or so windows on the desktop and I want to pick out three of them in no particular order. I tend to leave a lot of windows lying around with just what I want to see exposed on each, so it's a fairly large investment of my time to fix things if the stacking order gets changed in indiscriminate ways. Sawfish is a little broken now--it moves application focus but no longer moves the mouse cursor, which can result in the mouse cursor on one window but the focus on another.

(d) there's not always a window under the mouse

There is always a window under the mouse. As far as I know the mouse can't be anywhere except above the root window, and one can't delete the root window.

(e) some windows shouldn't get focus ever even if the mouse is over them

Which are those? I've seen some applications (mostly Xaw) that can't get focus with some window managers even when they want it and can get it under twm...I had assumed that was a window manager bug.

f) I understand that among those that use terminals heavily, there are many that like to launch applications in the background and continue working. But most users launch an application and then want to use it; defaulting to not focusing new windows just doesn't make sense.

It's not unusual for me to launch applications two or three at a time, especially if I need to have two or three of them working together on a project. I also have applications that have extremely long startup times (e.g. Galeon after a crash may take up to 10 minutes to become fully usable).

I sometimes do corbet's xv and ^C trick. Sometimes it doesn't work, e.g. when the xv window fills the whole screen and focus goes where the mouse is--on xv. There's an xterm trick which is to put the xterm in "secure keyboard" mode, which is essentially just a permanent input grab. Unlike the way that input grab usually used by menus, an input grab on xterm is actually useful, and AFAICT it's a feature missing from gnome-terminal and konsole.

Ideally the window manager could do this consistently across all applications--e.g. the window menu might have options that mean "lock keyboard input focus on this window until further notice" with options "even if I manipulate other windows or new windows appear" and "even if the window closes, no other application gets focus until I explicitly allow automatic focus selection again."

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

It'd be awesome if there was a way to determine where, how, and when an application was launched without something like needing to be launched with startup-notification. But there isn't (okay, 'when' is sort of available if the WM is running on the same machine as the app and uses system calls to determine when the OS started it, but even this time isn't what you really want--you want to know when the user clicked the mouse or pressed enter in order to cause the app to launch which occurred sometime before that; further for apps like firefox/mozilla/nautilus/epiphany/gnome-terminal/gedit/konqueror etc. that forward new window requests to other instances, only the old instance that forwards the request has the appropriate information and if it doesn't get forwarded then you're stuck and have to take wild guesses). Having an app try to determine if it was launched from a terminal somewhere just isn't possible. Anyway, it's just another part of why apps really need to be launched with startup-notification for this freedesktop.org focus-stealing-prevention stuff to work.