| |||||||||||||
GNOME and the way forwardGNOME and the way forwardPosted Aug 18, 2005 3:16 UTC (Thu) by corbet (editor, #1)In reply to: GNOME and the way forward by newren Parent article: GNOME and the way forward I'm running 2.11.90, according to RPM. I'll run a test again in the morning; I know 2.10 still had the problem. I was once told it was my problem, that new windows should get the focus always regardless or most users will get confused...
(Log in to post comments)
GNOME and the way forward Posted Aug 18, 2005 4:17 UTC (Thu) by elanthis (guest, #6227) [Link] I would think that whoever told you that certainly wasn't in any way a speaker for the GNOME project. (Keep in mind that the mailing lists and forums are almost entirely filled with people who are NOT GNOME developers, but just proponents or users. This post itself is from someone who is NOT a GNOME developers.)
Focus stealing prevention was present in 2.10, but was not entirely mature. 2.12 has quite a few improvements. I can attast at the very least that on both my Ubuntu Breezy-devel and Fedora Rawhide boxes that focus stealing prevention works. New windows popup without stealing focus.
Sometimes. The rules are that new windows get focus baed on user interaction with the system. The idea being that if I click a button which results in a new window opening, I probably wanted that new window to have focus. There are still a few glitches with all this as applications that are not updated to provide proper hints to the window manager may behave improperly as Metacity has to make some guesses on the user's intent.
Focus stealing Posted Aug 18, 2005 4:28 UTC (Thu) by corbet (editor, #1) [Link] With 2.11.90 it still happens. Easy example: type "gnome-terminal &" in a terminal emulator in the lower right corner. The new terminal window will appear in the upper left. Focus will move to the new window (whenever it appears) even though the pointer remains in the original window. If the new window is slow to appear, the focus will move at an unpredictable time in the future. It's annoying as hell. I use focus-follows-pointer and do not wish the system to ever do anything else.I also have a hell of a time with firefox snarfing the focus if the pointer passes over it briefly on the way to some other window. That problem has not gone away either.
Focus stealing Posted Aug 18, 2005 4:53 UTC (Thu) by newren (subscriber, #5160) [Link] type "gnome-terminal &" in a terminal emulator in the lower right corner...Focus will move to the new window (whenever it appears) even though the pointer remains in the original window. If the new window is slow to appear, the focus will move at an unpredictable time in the future.Yeah, focus-stealing-prevention requires apps to be launched with startup-notification to work, and launching them from the terminal doesn't do that. Sorry. Haven't been able to come up with a better solution (if you can think of one, let us know on wm-spec-list). Do a "export DESKTOP_STARTUP_ID=_TIME0" before launching as a hacky workaround. I also have a hell of a time with firefox snarfing the focus if the pointer passes over it briefly on the way to some other window.Um, you moved the mouse over the firefox window and are using focus-follows-mouse; why shouldn't it get focus? Or are you saying that firefox keeps the focus despite you continuing to move the mouse into other windows? (If the later, I've never seen it--is there any way you can find of more easily reproducing it?)
Focus stealing Posted Aug 18, 2005 12:49 UTC (Thu) by corbet (editor, #1) [Link] Yeah, focus-stealing-prevention requires apps to be launched with startup-notification to work, and launching them from the terminal doesn't do that. Sorry. That has been my mode of working since I first discovered X10. A common pattern, for example, is to fire off xv to look at an image file, then try to just make it go away with ^C. Doesn't work now, but it always used to work in older environments. Rather than using elaborate schemes involving race conditions between the user and new applications, why not just have the focus be on the window under the pointer, always?
Um, you moved the mouse over the firefox window and are using focus-follows-mouse; why shouldn't it get focus? Or are you saying that firefox keeps the focus despite you continuing to move the mouse into other windows? That's what I'm saying. My desktop tends to be a mess; image two emacs windows both of which are over a firefox window. Move the pointer from one emacs to the other, crossing over a small strip of the buried firefox window, and the focus may well end up on firefox. Then I usually do something like hit ^N half a dozen times and, rather than seeing the cursor move down, I'm rewarded with a pile of new firefox windows to clean up. Makes an editor grumpy, I tell you...
Focus stealing Posted Aug 18, 2005 14:00 UTC (Thu) by Klavs (subscriber, #10563) [Link] Not to be a troll, but that exact feature in KDE, is one of the things that keeps me running KDE.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. works nicely for me :) Also - if I in konsole start xclock - and the mouse stays over the konsole - xclock does not get focus, simply because it started.
So it seems it should be doable for Gnome as well.
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. ;-)
Focus stealing Posted Aug 18, 2005 16:17 UTC (Thu) by newren (subscriber, #5160) [Link] Rather than using elaborate schemes involving race conditions between the user and new applications, why not just have the focus be on the window under the pointer, always? Maybe because (a) that's not actually possible in X (though yes, we could get much closer), (b) it also suffers from race conditions the way you've described it, (c) it inherently causes breakage with various other parts of the UI, (d) there's not always a window under the mouse (okay, so I'm being picky--we do have both sloppy and mouse focus modes after all for users that have different preferences in this situation), (e) some windows shouldn't get focus ever even if the mouse is over them, and (f) it is counter-intuitive for most users? A little more explanation for those points that might not be obvious: 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. 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. 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. 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 is possible that a preference could be added (and one was proposed before by Havoc under the name "strict pointer mode", which I've talked about elsewhere in the comments here and the problems with understanding it), but I really need to know what it means. The comments in this article are helping, but if you read through it you'll probably find why it's hard to figure out what people really want (you described it first as "don't have windows take away focus while I'm busy with some app" which we can mostly get assuming apps are launched with startup-notification; now you describe it as focus-on-window-under-mouse-always which isn't quite possible and might entail more than you mean (do you really want keynav and window applets to be totally broken and to break apps that shouldn't take focus and to make an effort to rewrite all apps? or do you just want new windows to not be given focus? what about window placement and stacking for such new windows?); someone else tried to describe it in terms of what should happen when switching workspaces (probably alluding to an old Metacity bug) which is unrelated to new windows appearing. image two emacs windows both of which are over a firefox window. Move the pointer from one emacs to the other, crossing over a small strip of the buried firefox window, and the focus may well end up on firefox. This sounds like something that trying to have the WM enforce window with pointer has the focus may not fix; it's most likely some other deeper bug. I'd love to see a verbose debugging log:
Focus stealing Posted Aug 18, 2005 16:36 UTC (Thu) by tjc (subscriber, #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. 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.
Focus stealing Posted Aug 18, 2005 16:49 UTC (Thu) by newren (subscriber, #5160) [Link] Hehe ;-)
Honestly, though, the 10 second load time is being addressed; that's what focus-stealing-prevention is for. Perhaps you were trying to use this as a reason to request never-focus-new-windows but like others here, you're not really addressing the issue and just listing cases that it looks like we've already covered.
Now, if you said, "Yes, launched windows shouldn't steal focus if the user works with another app between the time the window is launched and when it is shown--but that doesn't work without apps being launched with startup-notification which may not be feasible for us terminal users and we'd really like a preference, even if a kludge, to just not focus new windows" or if you said "Yes, most users launch an app then use it but us terminal users like to launch multiple apps without using them until a delayed time later so could we have a way to make the WM behave smart given our different usage scenario?" (see also bug 151818 comment 22, second half of point 8 for where I addressed this exact case) then I'd have an easier time understanding. In particular, though, I'd like to know more about the "behave smart" in the latter case--what do should be done relative to focus? placement? stacking? interaction with keynav? etc., etc.
Focus stealing Posted Aug 18, 2005 18:02 UTC (Thu) by tjc (subscriber, #137) [Link] > Perhaps you were trying to use this as a reason to request never-focus-new-windows but like others here, you're not really addressing the issue and just listing cases that it looks like we've already covered.No, I'm not. I've learned from experience that requesting anything from the Gnome development team is pretty much a waste of time. > Now, if you said, "Yes, launched windows shouldn't steal focus if the user works with another app between the time the window is launched and when it is shown--but that doesn't work without apps being launched with startup-notification which may not be feasible for us terminal users and we'd really like a preference, even if a kludge, to just not focus new windows" Depending on well-written apps to deal with the problem just about eliminates any chance that the problem will be completely fixed, ever. > or if you said "Yes, most users launch an app then use it but us terminal users like to launch multiple apps without using them until a delayed time later so could we have a way to make the WM behave smart given our different usage scenario?" Forget about launching from a terminal, launching from Gnome panel is a problem. It still takes 10 seconds to load some apps, and I don't want to sit around doing nothing for 10 seconds while I wait, and I sure don't want to be interrupted by a new window stealing the focus. I know this problem is difficult to fix, but that doesn't mean that it isn't a problem. The fact that Windows XP handles this better than X should be some motivation to bite the bullet and fix the problems with X before writing a lot more software for a broken architecture. If it's a lot of work and disruption now, it will just be a bigger mess 5 years from now. The time to fix this is before Gnome gains widespread enterprise deployment, not after. The alternative is to hire a bunch of marketing people to try and tell us that it's not really broken, all our friends like Gnome, it must be you, etc.
Focus stealing Posted Aug 18, 2005 18:24 UTC (Thu) by newren (subscriber, #5160) [Link] I've learned from experience that requesting anything from the Gnome development team is pretty much a waste of time.I'm sorry you feel that way. I hope I'm not part of the problem (though I probably am--I can't even get a small amount of the stuff done that I'd like to do myself), but for what it's worth I personally am trying to both (a) get things to work right for the default case (the normal "Gnomeish" response) and (b) cover extra important edge cases and smaller usage scenarios where merited with additional options (that's the whole reason for my lengthy posts here--I'm not sure I fully understand strict pointer focus and the requests for it but I would like to).
Focus stealing Posted Aug 18, 2005 19:16 UTC (Thu) by tjc (subscriber, #137) [Link] > I hope I'm not part of the problemNo, your not. My dissatisfaction dates back to the transition from Gnome 1.x to 2.x.
Focus stealing Posted Aug 18, 2005 20:27 UTC (Thu) by pimlott (guest, #1535) [Link] > I hope I'm not part of the problem
Please take this message in good faith.
Consider your long reply to Jon ("Maybe because ..."). The tone of that message, as I read it, is, "let me tell you all the reasons that what you want is wrong (and PS you don't really understand what you're asking for)". Why not instead start from the premise that Jon is an intelligent, experienced, and thoughtful user, and therefore that what he wants is reasonable and valuable? Think, "satisfying Jon's request might make GNOME a better desktop", or even "making Jon a happy user could earn some serious karma".
I'm not suggesting you would ever intentionally belittle Jon. But I think many GNOME (and Mozilla) developers tend to read user complaints with a mindset of "correct him" rather than "learn from him".
Focus stealing Posted Aug 18, 2005 21:13 UTC (Thu) by newren (subscriber, #5160) [Link] Oh, crap. I didn't even realize I was coming across that way. Sorry about that, Jon. /me goes and bashes his head into the wall as penance
For what it's worth, I really did mean to come across as "the request as you've written probably isn't what you mean--could you clarify?" with a really verbose explanation of why I think he might mean something different. (I think he was getting at the fact that he didn't like the default of focusing new windows in the cases where there is no user interaction between launch and appearance of the window or when we don't know enough about when various user interactions occurred, but what he suggested encompassed way more--and I don't know if the extra stuff was intended or not. After working on a WM long enough you find that people request all kinds of variations of things and I really don't know what's being requested without getting more detail)
Other comments in this thread are similar; I think most all of them are getting at that specific default, but actually use examples that are tangentially related and/or include lots of other stuff that may or may not be intended. I really am trying to understand what the real issue is.
Again, sorry for coming across that way.
Focus stealing Posted Aug 18, 2005 21:32 UTC (Thu) by corbet (editor, #1) [Link] 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...
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. :-)
Focus stealing Posted Aug 19, 2005 4:39 UTC (Fri) by pimlott (guest, #1535) [Link] >/me goes and bashes his head into the wall as penance
Now, no need to hurt the wall. :-)
Focus stealing 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 mouseThere 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 themWhich 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."
Focus stealing Posted Aug 18, 2005 22:24 UTC (Thu) by newren (subscriber, #5160) [Link] Lots of interesting info in your post. Thanks! Some comments: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.Really? I had assumed (never actually checked) that it'd be a lot of hard work to modify toolkits to work without mouse and keyboard grabs. From the few things I had read on the matter, though, it doesn't look like toolkit authors are willing to make such a change--perhaps it causes lots of race conditions or other problems? (Man, I'm exposing my ignorance here...) 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.It's not very hard at all to place windows below the focused one and first in the alt-tab list. Also, the WM gets MapRequest events whenever an application tries to map a window (unless it's an override redirect window) and can just deny or delay the request so it could keep apps from un-minimizing themselves for the most part. 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.Try using Alt-Esc in metacity. Other WMs may have something like that too with an alternate keybinding. 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.Yes, I unfortunately used "window" as the user thinks of them instead of as the real X objects. Note that mose focus-follows-mouse users prefer a sloppy style meaning that windows are focused when the mouse enters them but they are not defocused on exit--and users don't consider the root window and other special windows (e.g. the taskbar) to count when the mouse enters them. Saying always keep the focus under the mouse is nice and all but this is just an example of how most people don't really mean that. 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.See section 4.1.7 of the ICCCM (e.g. at http://tronche.com/gui/x/icccm/sec-4.html). Basically, it's a violation of the ICCCM for the window manager to try to set focus to a window with the input field set to false.
Focus stealing Posted Aug 18, 2005 23:29 UTC (Thu) by zblaxell (subscriber, #26385) [Link] From the few things I had read on the matter, though, it doesn't look like toolkit authors are willing to make such a change--perhaps it causes lots of race conditions or other problems? (Man, I'm exposing my ignorance here...)There are one or two differences, especially in the select-no-entry case. With a grab you can have the user click on some non-menu surface, and keyboard accelerators can be used no matter where the mouse is. I'd imagine some users believe that they'd have to click off-menu to abort a menu selection (I once believed that, and it might be true for some applications with a do-it-yourself toolkit) as opposed to pressing Escape, or clicking on-menu and dragging off. Also, arrowing your way through the menu instead of using the mouse works only if the application that posted the menu already has keyboard focus for other reasons. Some menus in some toolkits will close if focus goes to another application while the menu is active. However, despite all the small changes, no menu that I've ever seen becomes unusable--all possible options, including "none of the above" can be selected with both keyboard and mouse. I wouldn't be surprised if there weren't a lot of applications out there that are built assuming the GUI toolkit is incapable of receiving input from other widgets while a menu is active. That would probably break a few programs, but none of the ones I've tried.
Focus stealing Posted Aug 18, 2005 19:37 UTC (Thu) by smoogen (subscriber, #97) [Link] Maybe GNOME applications should either be wrapped or self test if they are run from the command line or not. If they are then they could set the desktop notification flag themselves?
Focus stealing 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.
Focus stealing prevention Posted Aug 25, 2005 8:24 UTC (Thu) by stuart (subscriber, #623) [Link] So perhaps a solution to the first problem is that you don't steal focus if an application does not have startup-notification.
GNOME and the way forward Posted Aug 18, 2005 4:29 UTC (Thu) by newren (subscriber, #5160) [Link] It's possible that different issues have been confused, in particular focus-stealing-prevention and a strict pointer focus or a never-focus-any-window-preference. I'll try to explain each to possibly make it easier for you to understand what's going on, but I'm just taking wild guesses. If you file a bug I'll look at it and have a better chance of finding out what your expectations are and what's actually happening.
Basically, Metacity's goal is that windows should not be focused if between launching the window and its appearing the user has started using another application. That's what the focusing stealing prevention stuff is (whose mechanism is a freedesktop.org spec pioneered by Lubos Lunak of KWin and KDE fame, btw). This feature, though, depends on apps cooperating to work correctly. For the most part, apps using QT or GTK should work fine. Other apps, such as emacs, may cause some problems and defeat focus stealing prevention--because for such apps the WM has no way of knowing if the user is interacting with them (other than mouse clicks) and it also has no way of knowing at what xserver time the user caused them to be launched in order to figure out if the user has interacted with other apps while waiting for the window to appear. (Well...Soeren has suggested a workaround for the latter of these problems but we haven't gotten around to trying it out yet). There are also special cases where app authors need to help out (e.g. those apps that when launched don't actually open a window but instead tell a different instance of the same app to open a window for them). The final kink is that app authors can lie to the WM and/or use X calls to attempt to forcefully steal focus anyway (which it appears some do--sigh). That's all kind of a long-winded explanation of possible bugs, but yes the basic idea idea is to focus new windows if the user "isn't busy doing something else".
Now, some people have requested a window-is-focused-iff-pointer-is-in-it (which destroys/prevents keyboard navigation and potentially other things if followed 100%), for which "strict" pointer mode patches have been written. For the most part, though, these patches were really designed to fix dozens of bugs that used to exist in metacity in mouse and sloppy focus modes. But there is one issue left that wasn't just cop-out-workaround-for-ugly-bugs from such patches, namely a 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?
Also, there are people who are proponents of a never-focus-new-windows-no-matter-what behavior. This one I understand (lets you launch lots of applications or windows but keep working with your current one) but it doesn't exactly fit the normal user. Most users will launch an application and then want to use it as soon as it appears; if it's not focused they'll be annoyed that they have to move the mouse to the window and (for click-to-focus users) click on it before they can begin typing when the window appears.
Anyway, there's a long winded explanation to try to explain what you might be expecting and what might be occurring. But I'm just taking wild guesses here. File a bug and I'll take a look at it.
GNOME and the way forward Posted Aug 18, 2005 6:35 UTC (Thu) by sfeam (subscriber, #2841) [Link] Different strokes / different folks. I'm of the school that says nothing should ever steal the focus from a window I am typing in. Ditto for windows I am interacting with via mouse clicks. Basically I *never* want a new window or new app to steal focus. Are you saying I have to file a bug report in order to request that behaviour?
GNOME and the way forward Posted Aug 18, 2005 7:02 UTC (Thu) by jamesh (guest, #1159) [Link] The two constraints people usually want honoured for new window behaviour are:
The rules the focus stealing prevention code uses are essentially the following:
The idea here being to do the right thing without a preference. Unfortunately, some applications need modification to function correctly in this system (e.g. specifying where in the event stream a particular window was requested, or telling the window manager not to focus a new window that is not the result of a user action).
GNOME and the way forward Posted Aug 18, 2005 10:05 UTC (Thu) by jschrod (subscriber, #1646) [Link] If a user starts an application, they want to use it so it should be focused. I beg to differ. If I want to use an application, I move my mouse to it. I often start an application in the background, and will come back later to it. *I* decide when I come back to it, not the window manager's developer. This behaviour of GNOME is one of the main reasons why I don't use it, though I tried it several times. Cheers, Joachim
GNOME and the way forward Posted Aug 18, 2005 10:07 UTC (Thu) by kleptog (subscriber, #1183) [Link] 1. If a user starts an application, they want to use it so it should be focused.Interesting idea, but I disagree. I'm in front of my computer and if I want to use an app I will point my mouse at it. I'm probably not the target audience though. I'm running FVWM with 16 virtual desktops in a 4x4 matrix, one app per desktop. I use MouseFocus/SloppyFocus. When I switch to a new desktop (with the shortcut keys) I expect wherever the mouse lands to be the window with focus. If it lands on the background then the focus doesn't change i.e. it's off screen. You may find this strange but it's a 100% deterministic system and I can control my focus perfectly to acheive exactly what I want. What you describe is non-deterministic because it depends on the apps doing things I can't see. What I find most amazing is that strict-mouse-focus is the easiest system of all. Detect what the mouse is over, that window has focus. And no, clicking on it doesn't raise it either.
GNOME and the way forward Posted Aug 18, 2005 17:15 UTC (Thu) by newren (subscriber, #5160) [Link] Interesting idea, but I disagree. I'm in front of my computer and if I want to use an app I will point my mouse at it.Note that James said "two constraints people usually want honoured". See also bug 151818 comment 22 (second half of point 8 of that post), where I discussed this issue and the usage scenarios that would lead to whether users wanted new windows focused in addition to how they should be placed. Also, you seem to have ignored placement. What if the new window is big enough that it can't be placed onscreen without being placed where the pointer is? Should the window not be focused anyway? Or is it okay to focus it in that case? Should the WM attempt to avoid where the mouse is for window placement in general (that's racy if the user happens to be moving the mouse at the time the window appears...)? Should the new window be placed at the top of the stack of windows? Below the focus window in stacking (but hopefully as disjoint as possible in location)? Below all other windows to avoid races? Should it just not be shown until the user clicks on a button in the taskbar? What about apps that try to transfer focus from one of their already onscreen windows to another already onscreen window (and which may be needed in order for keynav to work correctly)--should such requests just be summarily denied because the user hasn't moved the mouse? What about alt-tab, the taskbar, and the window selector applet--should these all become no-ops and appear to be broken to the user unless the user moves the mouse at the same time? People are complaining but no one seems to be addressing all these other issues that would be needed in order to understand how to make the environment sane with a new preference. I'm probably not the target audience though. I'm running FVWM with 16 virtual desktops in a 4x4 matrix, one app per desktop. I use MouseFocus/SloppyFocus. When I switch to a new desktop (with the shortcut keys) I expect wherever the mouse lands to be the window with focus. If it lands on the background then the focus doesn't change i.e. it's off screen.Workspace switching behavior with existing windows isn't related to the decision about what to do with entirely new windows. It sounds like you're complaining about an old Metacity bug. You may find this strange but it's a 100% deterministic system and I can control my focus perfectly to acheive exactly what I want. What you describe is non-deterministic because it depends on the apps doing things I can't see. Actually, no it isn't 100% deterministic; windows can steal focus anyway. XSetInputFocus requests by apps are unconditionally granted by the XServer with the WM given no chance to prevent such focus changes (this is a bug in the X11 protocol--google for "Why X is not our ideal system" written in 1990 by some of the people who came up with the ICCCM; no, their suggestions for fixing this aren't part of X today). Granted, most apps won't do this to you but unless you've completely audited all the apps you are using (meaning the exact version of the apps that you are using), it isn't 100% deterministic. Further, you misunderstood what James said if you think that what he wrote "depends on apps doing things I can't see". Both your method and what he outlined should be deterministic modulo bugs. What I find most amazing is that strict-mouse-focus is the easiest system of all. Detect what the mouse is over, that window has focus. And no, clicking on it doesn't raise it either.Why should you be amazed that an environment which you are used to is the easiest for you? ;-) Also, making the window under the mouse always be the one with focus isn't actually possible under X--see my response to Jonathan elsewhere in the comments to this article. You can get an implementation that is closer than what Metacity currently allows, but all the ones I've seen destroy keyboard navigation which doesn't make sense to me (do people really want that? Or did no one consider the possibility of inbetween behavior that gets as close as possible without destroying keynav? I could implement either but I don't know what people really want). (I discussed orthogonality of raise with other actions elsewhere in comments under this article as well so I won't repeat here)
GNOME and the way forward Posted Aug 18, 2005 22:29 UTC (Thu) by kleptog (subscriber, #1183) [Link] Thanks for your responses, it's been nice to have someone who's at least attempting to understand the problem looking at this.Also, you seem to have ignored placement. Placement is simple. If there's room on the current desktop, place it there, if there isn't it puts an outline of the window on the screen and I place it with the mouse. Since I arrange for the desktop to be free whenever I start an app the placement is never that hard. I know exactly how long Galeon takes to startup and can jump to the desktop at the right time. This is only for top-level windows, for subwindows they just popup and like you say, they get focus if and only if I have the mouse there. If it's one of those dialogs that keeps popping up and I need to press no, I can place my mouse at the right place to meet it. If I don't care I'll keep typing in the window behind it and deal with the box when I want to. I don't know how FVWM does it, but it does work well. This does mean that subwindows, whenever possible, should popup in the same place, irrespective of where the mouse is. What about apps that try to transfer focus from one of their already onscreen windows to another already onscreen window [...] --should such requests just be summarily denied because the user hasn't moved the mouse? In short, yes. I control the focus, not the application. The app may ofcourse respectfully request the focus be moved and it can just as respectfully be ignored. As to your questions about the task-bar and alt-tab, I checked and it warps the mouse to the desktop and location so as to make the app have focus. But I never use those things. Like I said I have a 4x4 virtual desktop and my browser / mail client / etc have fixed desktops so with the keyboard I can just jump straight to the app I want. Alt-tab and task-bars tend to get the apps in a random order (that keeps changing) so I can't use them to get to an app in a deterministic way. One app per desktop remember... The input focus stealing, yes, I've seen that with Netscape 4.x if an app opened just as you were browsing the menu. Nasty stuff. As someone pointed out, why do menus need to steal focus when they don't actually need to. Everything works fine without. I worked out ways to break that focus. If an app I used did that a lot I wouldn't use it... Anyway, I'm one of those people who dislikes taskbars and desktop icons and I'll probably keep using FVWM no matter how good you make GNOME. I think overall you're doing a good job, I just hope that if I'm ever required to use GNOME somewhere, I'll be able to set it up with strict mouse focus. Have a nice day,
GNOME and the way forward Posted Aug 27, 2005 16:07 UTC (Sat) by ekj (guest, #1524) [Link] I don't want this. I have selected, in my preferences, how to give focus to a window, in my case "focus follows mouse". I selected that because that's what I want.The fact that I (at some time in the past) typed "Alt+F2 gimp" is no indication at all that I want gimp focused whenever it gets done loading. When I want to use it, I'll select it. The problem would be smaller if all apps had sub-second loadtimes but that's by far not the case.
GNOME and the way forward Posted Sep 2, 2005 21:36 UTC (Fri) by renox (subscriber, #23785) [Link] >The problem would be smaller if all apps had sub-second loadtimes but that's by far not the case.
Which is why I think that having 'transition-window' (note this isn't splash-screen which are totally other thing) would be great: each time you open an app, a window (quasi-empty at first, with just the tittle of the application and a progress bar for slow starting apps) should open: this would be very fast because the window is empty, then when the application is ready to be used, it replace the content of the window with the content and notice the user by changing the color of the application window and icon, for example.
Of course when the replacement occurs it should keep the shape defined by the user as you can iconify, resize the 'transition-window' even though the application is not ready to be used yet.
This should improve the life of users, but it can only works if the transition window can be raised very fast (but as it is mostly empty this shouldn't a problem, I think) and for application with a central unique window. For the gimp, it wouldn't work..
GNOME and the way forward Posted Aug 18, 2005 15:29 UTC (Thu) by newren (subscriber, #5160) [Link] Hehe, your explanation of your requested behavior doesn't quite match:I'm of the school that says nothing should ever steal the focus from a window I am typing in. Ditto for windows I am interacting with via mouse clicks.Translates as "don't transfer focus to a new window if I'm busy with another window (implying that a transfer of focus is okay if you're not busy with another window)". Note that Metacity does this. Basically I *never* want a new window or new app to steal focus.Translates as (rather obviously) "don't transfer focus to a new window regardless of whether I'm busy with another window". Metacity has no option for this, currently. A "strict" mouse focus has been proposed and in fact patched in by RHEL, Debian, and Ubuntu so it may well end up in Metacity itself. But the patch (in bug 152004) that proposed it was kind of muddied by the fact that it uses lots and lots of kludges to workaround dozens of other bugs that no longer exist so it was hard to differentiate between a real request and just a workaround for old bugs...
GNOME and the way forward Posted Aug 18, 2005 18:58 UTC (Thu) by loening (guest, #174) [Link] I'm also of the school that says nothing should ever steal the focus from a window that I'm typing in. But by "typing", I mean that I have been typing in that window, not that I necessarily have managed to type anything else between the time a new app has been started and the 0.2s it takes to popup a window on the screen.For the gnome-terminal example, if I type "gnome-terminal &" in the terminal window, I don't want the new terminal to grab the focus, even through the new window (at least on my 2GHz box) pops up faster then I can type another key. After reading through this very insightful thread, I now understand how the current behavior has been arrived upon in GNOME. But I would personally love an option to enable "new window doesn't steal focus unless it pops up under the cursor" behavior.
GNOME and the way forward Posted Aug 18, 2005 19:20 UTC (Thu) by newren (subscriber, #5160) [Link] So in other words we just have to place new windows where the mouse currently is and then you're fine with the new window taking focus?
GNOME and the way forward Posted Aug 18, 2005 19:59 UTC (Thu) by loening (guest, #174) [Link] I assume you're joking, but humor often doesn't translate well into text.
So just so we're clear. New windows should not take focus if another window has the focus, unless the new window has to pop up over the current window because there's no other spot for it to pop up.
Actual, after reading some of the new posts, an even better policy might be this: New window should not take focus if another window has the focus, and a new window should not pop-up over a window that has the focus. If the new window has to use screen real-estate that the focused window has, it should pop-under the focused window.
GNOME and the way forward Posted Aug 18, 2005 20:51 UTC (Thu) by newren (subscriber, #5160) [Link] I assume you're joking, but humor often doesn't translate well into text.Actually, no I wasn't. You'd be really surprised what you hear people request when you work on developing a window manager. I really was just trying to get you to clarify. (thanks for doing so).
GNOME and the way forward Posted Aug 18, 2005 8:30 UTC (Thu) by spitzak (guest, #4593) [Link] Keyboard navigation can be made to work in a strict focus-follows-pointerby *moving* the pointer. I have done this in flwm and it seems to work very well. When shortcuts are used to move the focus the mouse is moved to the nearest point in the window, plus a few pixels. If windows are able to grab focus on creation, the mouse can also be moved into it. However I believe that in focus-follows-pointer this behavior is never wanted, and in fact the opposite, moving the mouse out of the way of the new window automatically, may be better. However I have not tried this. People really are thrown off if a focus-follows-pointer if at times the focus and pointer do not match. Do not do it.
GNOME and the way forward Posted Aug 18, 2005 18:03 UTC (Thu) by newren (subscriber, #5160) [Link] Keyboard navigation can be made to work in a strict focus-follows-pointer by *moving* the pointer. I have done this in flwm and it seems to work very well. When shortcuts are used to move the focus the mouse is moved to the nearest point in the window, plus a few pixels.Fair point and sounds like a fine criteria for you; we considered it but didn't really like the idea of warping the pointer around. People really are thrown off if a focus-follows-pointer if at times the focus and pointer do not match. Do not do it.I understand in general, but there's a number of caveats: First, this just isn't possible due to application grabs of the mouse, windows that should not get focus at all, and windows that shouldn't be focused except in special circumstances (e.g. desktop windows that covers the entire screen or taskbars/panels). Second, not all people are surprised by this (in fact, many focus-follows-mouse users are surprised if applications they launched don't get focused; yes there was a time when Metacity didn't focus new windows and lots of users, including those using focus follow mouse, who got surprised). Third, it'd make clicks in the wrong place on the window list/taskbar really damaging as the user would then have to move the mouse a long ways to go and click where they really meant to on the taskbar. It's a tradeoff; and one where we picked allowing mouse navigation constraints (focus is under the mouse) to be temporarily suspended instead of warping the mouse. Fourth, if users are so confused by the focus not being under the mouse, why then do most focus follows mouse users seem to prefer don't-defocus-on-window-exit-unless-entering-a-new-window? It matters in more ways than you probably notice at first; in particular think about this hairy condition for users who use keynav to move a window a few workspaces away: if the pointer wasn't on any window in the first workspace but after switching a workspace it is on a different window than being moved, what should happen? Should the window that the mouse is over get focus? That would likely result in the user moving that new window to a different workspace when they meant to move the original window more than one workspace. Should the WM then warp the mouse to the window that moved workspaces? Seems really weird that the user can interact with the window for a while but the warping of the mouse doesn't happen until then. (Personally, I treat this as a "user is using the keyboard to navigate instead of the mouse so mouse navigation invariants are temporarily suspended until the user starts using the mouse again"--seems to work great and gracefully handle the conflict between keynav and mousenav without warping the pointer; haven't had complaints with this method so far, other than the "don't focus new windows ever" thing which can be an added option)
GNOME and the way forward Posted Aug 18, 2005 15:56 UTC (Thu) by tjc (subscriber, #137) [Link] > Also, there are people who are proponents of a never-focus-new-windows-no-matter-what behavior. This one I understand (lets you launch lots of applications or windows but keep working with your current one) but it doesn't exactly fit the normal user.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.
GNOME and the way forward Posted Aug 18, 2005 17:31 UTC (Thu) by newren (subscriber, #5160) [Link] 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.This is what we do in Metacity as well. It's an implementation of the focus stealing prevention spec pioneered by Lubos Lunak. 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.Ugh. Others who have requested a never-focus-new-windows have also requested a always-place-new-windows-on-top-even-if-not-given-focus. This is already a niche group. Why this explosion of options (and no, it's not just one more--you are only one of the people requesting just one more)? WMs that are the union of all features of all other WMs (e.g. Sawfish) aren't maintainable. Sorry to give this rant again, but N features toggles results in 2^N testing and maintenance workload which is just not realistic. I think it's worthwhile to try to add options to cover the larger of the niche usage groups (a strict focus option that causes new windows to not get focus, as proposed by Havoc in bug 152004 and heavily requested here, sounds reasonable). However (I hope I don't come across as offensive here), Metacity just isn't going to cover every case. Openbox, flwm, KWin, sawfish, fvwm, etc. (most of which can and have been used by users under Gnome), exist for users whom we can't satisfy with the preferences we are willing to add.
GNOME and the way forward Posted Aug 18, 2005 18:16 UTC (Thu) by tjc (subscriber, #137) [Link] > Ugh. Others who have requested a never-focus-new-windows have also requested a always-place-new-windows-on-top-even-if-not-given-focus.Just to clarify, what I'm suggesting is to *not* place new windows on top. Mapping them second from the top like Windows XP seems to work well. It's non-intrusive, and it doesn't seem to confuse new users.
GNOME and the way forward Posted Aug 18, 2005 18:28 UTC (Thu) by newren (subscriber, #5160) [Link] Right, I'd prefer to do things the way you suggest for a strict focus policy as I think it makes more sense, but I was just pointing out that others in months past have simultaneously requested a never-focus-new-windows AND always-place-new-windows-on-top.
GNOME and the way forward 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 navigationI've used window-is-focused-iff-pointer-is-in-it and keyboard navigation simultaneously since 14 years ago, starting with twm. I've used a few WM's since then, but I don't use window managers that can't do both. The trick is to move the mouse cursor and change the window stacking order when focus changes. Sawfish does the stacking order right--each candidate window is raised, but goes back to its former place in the stacking order if it was not ultimately selected, so keyboard navigation doesn't break the highly organized piles of windows that I build up. 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?You are mistaken. I really want this, and more. 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.
GNOME and the way forward Posted Aug 18, 2005 15:30 UTC (Thu) by tjc (subscriber, #137) [Link] > I was once told it was my problem, that new windows should get the focus always regardless or most users will get confused...Yeah, I've talked to the same person, and was told that these users are also confused by horizonal/vertical window mazimize options. I hope that moving windows doesn't confuse anyone, or we'll all be in trouble.
GNOME and the way forward Posted Aug 18, 2005 19:04 UTC (Thu) by bronson (subscriber, #4806) [Link] Ah, many of us have talked to the same Red Hat employee. His refusal to accept a simple patch to toggle horizontal and vertical maximization is what drove me to use the KWin window manager to show my Gnome desktop (works great, btw). Basically, he required that the h/v-maximize patch also "fix" the current atom behaviour, turning clean tens of lines patch into a few hundreds of lines of gobbledygook. If this continues to be the case, I'm skeptical that Metacity will EVER support toggling h/v-maximization.
GNOME and the way forward Posted Aug 18, 2005 20:10 UTC (Thu) by jeskritt (guest, #4092) [Link] I'm running FC4 and don't have this problem with my gnome desktop. Maybe there is an option you need to set?
|
|||||||||||||