| |||||||||||||
|
| |||||||||||||
Focus stealingFocus stealingPosted Aug 18, 2005 21:32 UTC (Thu) by corbet (editor, #1)In reply to: Focus stealing by newren Parent article: GNOME and the way forward No offense taken. 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. If a window pops up under the pointer, let it have the focus (in this case, there is a lot to be said for predictability of window placement, which metacity pretty much has). In another posting you said, I believe, that the above was not possible with X. But it used to work that way. It's only with GNOME 2 that I started running into weird focus stuff. Honestly, to me, the "focus stealing prevention" stuff which tries to figure out if you are actively engaged with another application or not looks like an ugly hack. Something like that will always be problematic to get right. It's a highly modal, timing-dependent interface which seems guaranteed to surprise people. My own experience says that, when you start looking at that sort of approach, you've missed a turn somewhere. In focus-follows-pointer mode, at least, why not just leave the focus under the pointer? It must be possible; the bare X server works that way by default...
(Log in to post comments)
Focus stealing Posted Aug 18, 2005 23:18 UTC (Thu) by newren (subscriber, #5160) [Link] 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).
Focus stealing Posted Aug 22, 2005 5:03 UTC (Mon) by EricBackus (guest, #2816) [Link] newren wrote:> Okay, you reiterated that you want the window under the pointer to > always have focus. But then you went and stated two exceptions. Actually, I see only one exception in Jon's response--an application grabbing the mouse. And I think both he and you acknowledged that there's nothing for the window manager to do in this case anyway. I'm not a Gnome user, so maybe my opinions on this are not very important. For what it's worth, I use KDE set to "Focus Follows Mouse", which DOES give the focus to new windows. But there is an alternative setting "Focus Under Mouse" which sounds like it does exactly what Jon is asking for. In response to your questions, I can provide my own answers: * The window list on the taskbar, like many things on the taskbar, is a special case. I'd expect having the mouse over the taskbar to be much like having the mouse over the background, so I don't see anything contradictory about making a click on the window list switch window focus just as though you briefly moved the mouse over the new application. * Alt-tab or alt-esc could perhaps warp the pointer. If you don't warp the pointer, perhaps you could merely top the selected application, but leave focus wherever the mouse is. I don't use these so I don't really have an opinion. * I also don't use the keyboard to move applications between workspaces. But if I did, and doing this puts the mouse over a different application, it sure seems like it *should* give that application the focus. But the above answers aside, I suspect that what Jon wants is simply to have new applications NOT automatically get focus, while leaving essentially everything else about window focus alone.
Focus stealing Posted Aug 30, 2005 6:04 UTC (Tue) by newren (subscriber, #5160) [Link] Sorry for the slow response...
> Actually, I see only one exception in Jon's response--an application
The other was "If focus remains when the pointer goes onto the background, that's OK." There is always a window under the mouse, even if it's the background window (the thingy drawn by nautilus with the icons on it) or the root window when nothing like nautilus is running (the root window will be a concept most users are unaware of as it's kind of an x implementational detail though it is exposed to some extent in some environments so some users do know about it). Allowing a window to retain focus despite the mouse being over a different window, such as the nautilus background window or root window, is an exception to the "window under the pointer has the focus, always" rule. Some users may not realize that it's an exception, but that's kind of my point--there are likely other exceptions that the user doesn't know about or doesn't realize that they are exceptions. I want to know what the exceptions are and what aren't.
> But there is an alternative setting "Focus
It may be exactly what he's asking for, but that's what I'm trying to find out. Note that "Focus Under Mouse" in KWin destroys keynav (as claimed by KWin itself). That seems strange to me. It may actually be what users want, but I wanted to find out if perhaps something that doesn't focus new windows without destroying keynav might be more desirable. There's a number of other behaviors I need to get nailed down as well...
> * I also don't use the keyboard to move applications between workspaces.
Yeah, that's the initial response of everyone that hasn't tried this (and it was the way I initially coded it too; I definitely was in the "everyone" group at one point). It seems to make sense. After all, if a user switches workspaces without moving a window with them we definitely want to focus the new window under the mouse. It isn't obvious without looking closer why things would be different when bringing a window with you while switching workspaces. So, let's look a little closer...
Let's say you were trying to move the original application, A, two workspaces to the right using keybindings. If the mouse is over the desktop instead of A, but A is still active (meaning that this can only happen with "sloppy" focus) then there's a special case: If another application, B, happens to be at the same coordinates where the mouse is in the intermediate workspace, and we focus B after the first workspace change like you suggest, that will make it impossible for the user to get application A where they want it without moving the mouse. But the thing is, users aren't aware of this. Instead, they just do this expecting things to work and then get really surprised when A moves only one workspace and B ("some random app") also moves one workspace...and it does take them a while to figure out what is really going on. Further, even if the user only moves one workspace over, they are moving A with them which means they almost certainly have an intent to continue interacting with that window (just as if the user alt-tabbed to it).
So focusing B really doesn't make sense (at least not for any use cases I've ever seen--maybe there are users out there, perhaps ones that don't mind keybindings being broken altogether, that would like this?). Anyway, ever since we switched from focusing the window B in this specific case, all the complaints about this issue stopped (which is surprising--virtually any change you make in a window manager, including "obvious" bugfixes, almost always results in bug reports with people requesting an option for the old behavior).
> But the above answers aside, I suspect that what Jon wants is simply to
Good, I'm glad to hear that someone else is coming to the same conclusion. :-)
|
|
||||||||||||