Focus stealing

Focus stealing

FWIW, what I want is this: the window under the pointer has the focus, always. If focus remains when the pointer goes onto the background, that's OK. If some rude application grabs it, there's little to be done - but that should not happen for much of anything beyond things like pulldown menus.

Okay, you reiterated that you want the window under the pointer to always have focus. But then you went and stated two exceptions. So you don't really mean for the rule to apply rigidly--but in what other cases should it not apply, if any? Here's some questions: If the user clicks on an item in the window list on the taskbar, should it be a no-op (sounds like that makes the window list applet useless--should the WM to disallow the existence of window list and window selector applets for your preferred focus mode? or is it okay to break the window-under-the-mouse-has-focus constraints here too?) What if the user tries to use alt-tab or alt-esc to switch which application has focus (no-op and break keyboard navigation? suspend mouse navigation rules temporarily since the user isn't using the mouse to navigate? warp the pointer?) What if the mouse pointer is over the background, the focus is on app A, and the user wants to use the keyboard to move app A from its current workspace and place it two workspaces to the right -- but app B has a window right where the mouse is in the intermediate workspace? In this case, if you focus app B after the first workspace switch (because it is under the mouse after all), then the user will be surprised if they rapidly hit the keybinding twice--they will have expected app A to move two workspaces but instead it only moved one while app B also moved one (yes, this was a real bug report--I'm not making it up). Is it okay to ignore the window-under-the-mouse-has-focus case here too? What about windows that don't take input focus?

I think that what you want is sloppy focus with its invariant (focus should be on the window under the mouse if there is one, otherwise focus should be on the most recently used window) held to be more important than focusing new windows with everything else kept the same, i.e. a don't-focus-new-windows-option. We explicitly decided to break the invariant in the new window case merely because the majority of users are surprised if new windows don't get focus (see our how to get focus right document and search for "strict"), but I believe we could add an option for not breaking the invariant in this case. I'm guessing that's what you want...am I right?

In another posting you said, I believe, that the above was not possible with X. But it used to work that way.

Look a little closer. Try this: bring up the menu in one of your apps, but don't click any of the items. Move your mouse to a different window altogether. Note that the application with the menu open still has focus and the menu is still up, and the window you moved the mouse into doesn't have focus. The application with the open menu has a mouse grab so that the WM doesn't know about the mouse entering the new window and is powerless to enforce the constraint you requested. (Note: there are some apps for which this little exercise won't work as they don't actually do a mouse grab, but most all apps do)

Also, try this: Open up a nautilus window. Pick an item and start dragging it elsewhere, including over other windows as though you were going to drop it on one of them. Notice that none of the windows get focused or raised when you move over them. We would really like to focus and/or raise those other windows when the user drags items over them to help them drop it in the right location (especially since it may be obscured), but we can't because the app where the DnD started has a mouse grab (although maybe if gtk+ sent the client messages for XDND with a nonzero event mask then maybe we could workaround this? I need to get an answer from Owen on that...)

I don't believe that either of those cases worked any differently in past with an X window manager (though there are efforts at fixing the latter via alternative methods and I believe I heard that KWin might have that up and running for QT apps at least...). Yes, we could get closer to having window-under-mouse-has-focus, but we can't make it 100%--and there are many ways in which it's not 100% where even most users of focus follows mouse probably don't want things changed. (And yes, I'll grant that the new window thing apparently is an example of where there's a large number of focus follows mouse users who do want a change to bring it closer to 100%, and that specific case is listed in the how-to-get-focus-right document I referenced above, but I'm not at all convinced that changes are wanted/needed for the other cases--at least, not yet).