| |||||||||||||
|
| |||||||||||||
GNOME and the way forwardGNOME and the way forwardPosted Aug 18, 2005 7:02 UTC (Thu) by jamesh (subscriber, #1159)In reply to: GNOME and the way forward by sfeam Parent article: GNOME and the way forward
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).
(Log in to post comments)
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..
|
|
||||||||||||