Ian Burrell wrote:

On 1/31/06, Miles Lane miles.lane@gmail.com wrote:

...

I cannot understand why on earth xorg or Gnome has been changed to render new application behind gnome-terminal. Every time I run a program (surprise!) I want to use it. I don't want to keep playing around with gnome-terminal. So, can we please strip this change out of Fedora Core?

I much prefer the new behavior. I used to always have trouble typing going into the wrong window when a new application started while I was typing into another. No more sending the root password over IM. Personally, I think apps should show above but never ever take focus. I am pretty sure apps can say that their modal dialogs should show above and get focus so they don't end up hidden.

The problem I have with that is that the popup dialogs are the worst offenders. I'll be typing into a word processor, and a long running background process pops up a dialog saying, "An unexpected error has occurred. Delete the database?" just as I'm about to type <TAB> <ENTER>. Bye-bye database!

On 1/31/06, Jeff Spaleta jspaleta@gmail.com wrote:

On 1/31/06, Robert Nichols rnicholsNOSPAM@comcast.net wrote:

...

The problem I have with that is that the popup dialogs are the worst offenders. I'll be typing into a word processor, and a long running background process pops up a dialog saying, "An unexpected error has occurred. Delete the database?" just as I'm about to type <TAB> <ENTER>. Bye-bye database!

but at the same time... having the pop up dialogs "pop-under" terminal windows in a way that you can't see them at all is also a problem.

Here's an example, the nm-applet has a keyring manager dialog that opens when it starts up. This dialog should be rendered above other windows, since it requires user input for important system functionality to be set up (wireless networking). Since this change, I see a flash when nm-applet starts, then I have to dig around to get to the dialog.

The most aggrevating example, though, is when I start ANY application from gnome-terminal (emacs, amarok, firefox, whatever). I now have to click on the application window to give it focus. I hate this! I, personally, think it is brain-dead to not give focus to applications when they start (with the exception of dialogs which should be "system modal" in Windows parlance).

Miles

On 1/31/06, Rudi Chiarito nutello@sweetness.com wrote:

Anyway, do you do anything with gnome-terminal or any other program after you start the application, but before its window actually opens? Metacity's focus-stealing prevention is supposed to kick in only if you interact with anything else after you started the application - the new window then will not grab the focus. It's not supposed to be unconditional, unless there's a bug that ought to be reported.

Its defnitely not working like you describe it should. metacity is unconditionally prefering to keep the focus on the terminal, for whatever application i start from the terminal even if all i do is hit enter..whether the mouse is over the terminal or not...whether or not i touch anything at all before the program opens My favorite side-effect of focus stealing protection is starting mplayer in fullscreen mode from the terminal and having the focus stealing protection not only have mplayer's full screen window show up under the gnome-terminal.. but "under" the gnome-panel as a well. It's quite amusing.

-jef

On 1/31/06, Joshua M Thompson funaho@jurai.org wrote:

On Tue, 2006-01-31 at 21:51 -0500, Jeff Spaleta wrote:

...

My favorite side-effect of focus stealing protection is starting mplayer in fullscreen mode from the terminal and having the focus stealing protection not only have mplayer's full screen window show up under the gnome-terminal.. but "under" the gnome-panel as a well. It's quite amusing.

This is one of the two times I find the new behavior to be most annoying. The other is when I run vncviewer to connect to my home machine from work and the password dialog pops up behind all my other windows, forcing me to move my hands to the mouse and bring it forward to click on it (alt-tabbing in and out of terminal windows seems to act weird.)

Please add your complaint to the bug report. Commenting here is not likely to result is this getting fixed.

-Miles

On Tue, Jan 31, 2006 at 09:09:18PM -0800, Miles Lane wrote:

Are you a FC developer? Have you checked the behavior?

I can't at the moment, as I am away from my Rawhide boxes.

It is unconditional. So, I should file a bug, eh?

Okay, I found it. It's this change:

http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mo... http://tinyurl.com/amwfc

It was partially backed out a few days later with this: http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mo... http://tinyurl.com/9fsgn

The new behaviour is still there for terminals.

Again, I think Fedora should reject this change to Metacity. I know that Redhat maintains custom kernel patches. Can we have a Metacity that doesn't implement this nutty window management?

This is where the author of the change explains the rationale:

http://bugzilla.gnome.org/show_bug.cgi?id=326159

Does Fedora Core have any influence over the development decisions of the Metacity project? Are we simply at the mercy of their whims?

I think at least a couple of Metacity developers, including the person that started the project, are RH employees. :-)

2006/2/1, Miles Lane miles.lane@gmail.com:

On 1/31/06, Rudi Chiarito nutello@sweetness.com wrote:

...

On Tue, Jan 31, 2006 at 05:23:20PM -0800, Miles Lane wrote:

...

The most aggrevating example, though, is when I start ANY application from gnome-terminal (emacs, amarok, firefox, whatever). I now have to click on the application window to give it focus. I hate this! I, personally, think it is brain-dead to not give focus to applications when they start (with the exception of dialogs which should be "system modal" in Windows parlance).

What if you start something in the background in your shell? GNOME has no way to know whether you just typed "emacs" or "emacs &". In the latter case you don't necessarily want the focus transferred to Emacs.

When I use "emacs &", it doesn't mean I want to continue what I was doing in the shell and use emacs later. In my usage, it means that I want to be _able_ to switch back and forth between emacs and shell commands, but I want to use emacs immediately. If I didn't want to interact emacs immediately, I would wait until later to start it up.

...

Anyway, do you do anything with gnome-terminal or any other program after you start the application, but before its window actually opens?

I have tried not doing anything until the executed program window is displayed. The program window still shows up beneath the terminal window.

...

Metacity's focus-stealing prevention is supposed to kick in only if you interact with anything else after you started the application - the new window then will not grab the focus.

I am not talking about focus, I am talking about what windows are shown on top! Personally, I expect focus to always go to the top window.

...

It's not supposed to be unconditional, unless there's a bug that ought to be reported. What happens if you enter "emacs" and keep your hands away from the mouse and the keyboard?

Are you a FC developer? Have you checked the behavior? It is unconditional. So, I should file a bug, eh?

Again, I think Fedora should reject this change to Metacity. I know that Redhat maintains custom kernel patches. Can we have a Metacity that doesn't implement this nutty window management?

Does Fedora Core have any influence over the development decisions of the Metacity project? Are we simply at the mercy of their whims?

     Miles

-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list

i am sure that if you have really good arguments a single person has influence aswell.

regards, rudolf kastl

p.s. i think such a setting requires a trainable ai... when do we get trainable ai for the gnome desktop behaviour?

Miles Lane miles.lane@gmail.com wrote:

When I use "emacs &", it doesn't mean I want to continue what I was doing in the shell and use emacs later. In my usage, it means that I want to be _able_ to switch back and forth between emacs and shell commands, but I want to use emacs immediately.

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.

jon

On 2/1/06, Jonathan Corbet lwn-fedora-test@lwn.net 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

Once upon a time, Dave Atkins thedave@ix.netcom.com said:

I do wish there were separate gestures (besides mouseover). So, I could left click the title, for foreground and keyboard focus, and right click for just keyboard focus. Or something.

With a configurable window manager, you could do things like that. However, GNOME developers know best, so metacity won't let you do it the way you want.

The way to solve this dilemma is to provide a user option to change the behavior. Everyone will then be happy, or at least happier, and I needn't impose my preferences on others.

--- Vladimir

On Tue, 2006-01-31 at 17:23 -0800, Miles Lane wrote:

On 1/31/06, Jeff Spaleta jspaleta@gmail.com wrote:

...

On 1/31/06, Robert Nichols rnicholsNOSPAM@comcast.net wrote:

...

The problem I have with that is that the popup dialogs are the worst offenders. I'll be typing into a word processor, and a long running background process pops up a dialog saying, "An unexpected error has occurred. Delete the database?" just as I'm about to type <TAB> <ENTER>. Bye-bye database!

but at the same time... having the pop up dialogs "pop-under" terminal windows in a way that you can't see them at all is also a problem.

Here's an example, the nm-applet has a keyring manager dialog that opens when it starts up. This dialog should be rendered above other windows, since it requires user input for important system functionality to be set up (wireless networking). Since this change, I see a flash when nm-applet starts, then I have to dig around to get to the dialog.

The most aggrevating example, though, is when I start ANY application from gnome-terminal (emacs, amarok, firefox, whatever). I now have to click on the application window to give it focus. I hate this! I, personally, think it is brain-dead to not give focus to applications when they start (with the exception of dialogs which should be "system modal" in Windows parlance).

  Miles

On 9/13/06, Susan Crayne crayne@us.ibm.com wrote:

Miles Lane <miles.lane <at> gmail.com> writes:

...

The most aggrevating example, though, is when I start ANY application from gnome-terminal (emacs, amarok, firefox, whatever). I now have to click on the application window to give it focus. I hate this! I, personally, think it is brain-dead to not give focus to applications when they start (with the exception of dialogs which should be "system modal" in Windows parlance).

  Miles

Would this "feature" also affect XUL dialogs in Firefox 1.5? I have written an application which works fine in FC4, Firefox 1.07, but in FC5, dialogs sometimes come up without the focus. If this is a bug, I think it is in FC5, since the problem doesn't occur in Windows with Firefox 1.5. I'm just trying to figure out where to report this problem.

Hello Susan,

I suspect that your problem is not related to the code that keeps gnome-terminal windows on top. You should check with the Mozilla/Firefox developers. I'd be quite surprised if Firefox doesn't have its own window management code for all Firefox windows and dialogs.

Here are some resources where you might be able to get more help/information:

Subscribe to the quality assurance list for Mozilla: https://lists.mozilla.org/listinfo/dev-quality

Internet Relay Chat: irc://irc.mozilla.org/bugs (for discussing bugs) irc://irc.mozilla.org/qa (for asking about Firefox QA)

Access the Bugzilla bug database for Firefox (search for issues like yours or add a bug report): https://bugzilla.mozilla.org/enter_bug.cgi?format=guided

I hope this helps, Miles

On Tue, Jan 31, 2006 at 06:23:07PM -0600, Robert Nichols wrote:

The problem I have with that is that the popup dialogs are the worst offenders. I'll be typing into a word processor, and a long running background process pops up a dialog saying, "An unexpected error has occurred. Delete the database?" just as I'm about to type <TAB> <ENTER>. Bye-bye database!

I think Firefox disables the buttons in dialogs that are not focused, so you don't end up activating buttons by mistake when you were simply trying to focus the dialog (especially if the dialog is for the most part covered). You click once to focus and once again to select the button.

The extension installation dialog keeps its crucial button ('Install') disabled until a timeout of a few seconds occurs. This can help a lot with scenarios like yours. And the countdown doesn't even start if the dialog is not focused.

Maybe all dialogs whose actions can't be undone should behave like that. Application windows shouldn't need to have their controls disabled while unfocused.

Miles Lane wrote:

...

This is the upstream behavior of metacity 2.10. I don't think there is a gconf key to customzie the behavior. You could use a different window manager which can be customized. I think kwin, the KDE window manager, allows focus stealing prevention to be customized.

This is exactly the sort of thing that drives me nuts with Gnome. The Ximian HIG/usability folks come up with some whacko default and then make it impossible for users to work around it. Who is it who decided to change this Metacity behavior? I cannot believe that this is going to be a usability benefit for most users. Argh! This may drive me back to KDE again.

I don't do things serially: a little while ago I clicked a link in some email, the went on to other mail (probably in a different client, I use Mozilla Mail and Thunderbird about equally).

I really don't want Mozilla taking me away from reading my email, I'll get to the website in my own time.

One of the most annoying assumptions programmers for Windows seem to assume is people always do things serially. "Don't do anything else while you burn a CD." "You can't do anything else while you read the contents of your Olympus Digital Voice Recorder." Bah.

I currently have stuff open on seven desktops in KDE and often have more. My window list currently runs to two columns and often to more.