On 2/1/06, Jonathan Corbet <lwn-fedora-test@xxxxxxx> wrote: > When I type "ooffice file.odt &" it doesn't mean I want to stop all work > on anything else until openoffice gets around to talking to me. if I > type "gthumb image.jpg &" it means I want to see the image, but I don't > necessarily want to type at it. I have to say that the new focus > behavior has improved my life considerably. I hope it doesn't go away. No, it shouldn't go away. It addresses the fundamental problem that its trying to address... sadly it seems to treat the terminal as a special sort of window... which is a hack. The problem is that its impact situations it wasn't designed for. Metacity just needs to get a weebit smarter when trying to determine if/when to engage the automatic focus protection. With it strictly on or with it strictly off, this feature (or lack of the feature depending on your pov) has usability issues. Why is that? because the terminal does not fit in Gnome's usability model at all..and it will never fit. The terminal is a square peg in gnome's round hole. I think its absolutely pointless for gnome to be spending any cycles trying to shoehorn terminal interaction into its usability model as a special case. Just leave the terminal alone and go back to focusing on keeping your target users out of the terminal all together. Once a user drops into a terminal to do anything they are outside the design scope of Gnome's target and Gnome needs to recognize that and stop trying to special case the terminal. Keep the implemented features inside the scope of the design target and stop over-reaching into cli interaction as a special case. If there is a way forward as the terminal as a special case, and I'm not sure their should be, I think the way forward is trying to train metacity to understand if the terminal is in "active" use. The protection afforded by the focus stealing protection makes a lot of sense when you narrowly define the problem as making sure that actively typed input for the terminal doesn't get stolen by a newly mapped window. But once you start dealing with situations where you launch an application and the terminal recieves absolutely no keystrokes from the moment the new application launch is initiated in the terminal, the feature is outside of its original design scope and gets in the way of how some terminal users expect things to work. Again I will note that users who prefer the terminal to get crap done are NOT the target audience for the gnome desktop at large. In my perfect world, this protection feature would have some sort of built in activity metric to try to make sure that focus stealing protection would only engage if the terminal was in active use. If I lauch openoffice from a terminal and I don't send the terminal an input for several seconds.. why should focus protection engage? Why exactly should the terminal stay on top? The terminal is a very flexible interface that is outside the scope of the Gnome design target and making assumptions about "typical" usage of the terminal by people who prefer to use the terminal instead of desktop centric methods can not justified inside the scope of gnome's overall design focus. I can imagine making metacity smarter two different ways. One way is to have it keep a time measurement of time since last input to the focused window and if the time is "too short" the window keeps focus when a new window is mapped. "too short" would have to be fine tunable. The problem here is if "too short" isn't long enough, you won't be solving the original problem of protection. The newly mapped window might show up too quickly for this method to be effective at preventing focus stealing. The other way around it is to have the focused terminal window always keep focus when a new window is mapped and then let metacity start watching for input into the focused window. If there isn't input for "long enough" after the mapping of the new window then metacity gives focus to the newly mapped window (a short pre-defined time after its mapped). "too long" would have to be fined tuned. If a new window is mapped quickly this method doesn't have a problem... metacity waits a pre-defined amount of time to switch focus to that window. Example assuming metacity waits 2 seconds looking for input to the terminal: *using a terminal and you launch vncviewer from the terminal but there is no input into the terminal window from the moment vncviewer is lancuhed *the vncviewer password window is mapped in under a second and pops under the focused terminal window, hidden from view *metacity is configured to wait a 2 seconds before switching focus so the terminal window and holds focus on the terminal window for 2 seconds seeing if there is any keyboard input into the terminal. *seeing no keyboard input, metacity changes focus to the newly mapped password entry window appears This allows the terminal to keep focus if and only if its being actively used for input in the pre-defined amount of time after a new window is mapped. newly mapped windows will not get in the way of active terminal input AND just as importantly terminal users expecting newly mapped input windows won't have to go hunting for them if they aren't actively using the terminal. All they have to do is wait a short amount of time and the inactive terminal loses focus and goes down in the stack. Any keyboard press while the terminal is in focus during that short period of time will cause metacity to retain focus for the terminal.. so users who want to retain focus simply have to ping the keyboard with a keystroke. Everyone wins.. without touching the mouse. if we want the terminal to always stay on top... metacity can re-impliment the per-window "stay on top" feature which it had at one point (which many window managers have). Always keeping the terminal on top regardless of input activity into the terminal is a preferential abuse of the focus stealing protection feature to mimic "stay on top" stacking behavior just for the terminal. If "stay on top" is going to be implemented...implement it in a more general way so ALL input windows can make use of it. I think its rather short-sighted to suggest that terminals are the only things which deserve the "stay on top" protection as compared to other types of input spaces. Considering that Gnome is focused on keeping their target users away from the terminal as much as possible.. preferentially targetting terminal behavior with window manager features seems very much outside of the design priorities for Gnome to me. Stop overreaching beyond Gnome's design. If the terminal interaction is not the focus of the Gnome desktop.. stop trying to half-ass constrain how terminal interaction works but instead implement features which apply equally well to ALL windows which can take text input. -jef"the key is respecting the limitations of the design model and not trying to special case how you treat everything outside of that design goal... just let the terminal exist and accept the fact that the details of terminal interaction is not inside the Gnome design focus"spaleta -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list