| |||||||||||||
|
| |||||||||||||
GNOME and the way forwardGNOME and the way forwardPosted Aug 18, 2005 4:29 UTC (Thu) by newren (subscriber, #5160)In reply to: GNOME and the way forward by corbet Parent article: GNOME and the way forward
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.
(Log in to post comments)
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 (subscriber, #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 (subscriber, #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 (guest, #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 (guest, #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 (guest, #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.
|
|
||||||||||||