| |||||||||||||
Focus stealingFocus stealingPosted Aug 30, 2005 6:04 UTC (Tue) by newren (subscriber, #5160)In reply to: Focus stealing by EricBackus Parent article: GNOME and the way forward
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. :-)
(Log in to post comments)
|
|||||||||||||