Thomas: starting new applications is almost simple: If I use the panel to open an application, say OpenOffice, then after my click nothing should have focus,* because last click was on the panel's menu window, which doesn't exist anymore. So, if I don't give the focus to anything (e.g., by clicking in a window, or using alt-tab), then the newly created window should receive it (it's not stealing, since no one has it). If I do give some window the focus before the new one has a chance to receive it, then it shouldn't be stolen.
(* Note that this isn't exactly so: somehow the last window used before the panel gets focus when the panel closes, I'm not sure how.) Starting things in other ways (e.g., when opening a file from Nautilus or Firefox, or using a global shortcut), is a tiny step beyond that, since an app. keeps having focus. My opinion is that if I use the focus in any way** after giving the command that opens a window, then the window shouldn't receive it. If I don't use the focus, than it means I'm waiting for the new window, so it should get its focus. (** Use focus means either changing the widget that has focus, or acting on a widget. The only thing I can think of that isn't included is moving the mouse, but some unusual input methods may have more. Gestures, for instance. I _think_ if you replace 'widget' with 'window'—Metacity doesn't normally know what a window contains—you get a very good approximation of perfect behavior.) AFAIK the above rules should be enough*** to provide very good user interaction for pretty much window creation (in fact, applications should do it for all _their_ windows, except if they're modal). The only thing missing is what happens if the initial focus is on the desktop, but I think the above is already hard enough to worry about this. (*** As long as there's a _good_ type of notification for "waiting" applications. Flashing the task-bar isn't enough; for example, I don't have one on this computer, and I have it hidden on my other machine.) ===== In short, if the user doesn't take any action (other than moving the mouse) between the moment a "command is given" and the moment that command "opens a window", then the new window should receive focus. Otherwise, it shouldn't be focused (unless it's modal, of course) and shouldn't be above the focused window (unless it's modal, of course; don't laugh, I've seen it happen). I'm not sure if a window manager can find out the command that resulted in opening a window. But (1) if the new window belongs to the same process, then the window manager doesn't care, does it? And (2) if the new window belongs to a new process, I think you can use its process creation time as a good approximation of that point. (The mouse listener or whatever that creates a process is probably quick; it's loading all the data and building a window that's slow, which all happens after the process is created.) -- 'Downloading package information' and 'building dependency tree' progress dialogs steal focus https://bugs.launchpad.net/bugs/35876 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
