Do not raise windows or dialogs without user input

[Triqui]

I'm using gnome, don't know about others.

There was a topic on brainstorm about this: http://brainstorm.ubuntu.com/idea/17434/
I wrote a comment in that one (User Triqui) and I whish this can be solved.
Cause I think it's more important than only password fields.
The front/current window must keep the focus no matter what. Only user input should move the focus away.

For instance:
I need to copy something to a remote server. In fact several remote servers.
So I start opening connections with them.
Most of the times I'll type half of the username in the login window for the first server I opened and the other half in the login window for the second one. So I have to wait for all the login windows to show up.
When I have typed all the users and password, sometimes they will take some more time to actually open a window.
So I go to my personal folder and start moving, renaming, compressing the files I have to copy.
Most of the times, the windows from the servers start popping up and then I cannot finish what I was doing until all the windows are open. It's very difficult to click on files of select some of them and apply some commands while windows keep opening in front of the window you are using. So I have to wait again.
Then I start copying files to the different servers, and maybe deleting some old versions from them. I start doing it for one server then for the next one and so on. But when I copy/move/delete and then move to the next window to do the same thing, this "operations on files" progress window keeps moving to the front, so I have to click back in the window behind to continue copying/moving/deleting.

This is just an example, and it's not so bad, since all I have to do is forget multitasking and wait for every single operation to complete before I do something else.
The real problem arises when I'm writing a mail or renaming a file or something like that and them some window pops up unexpectedly and then I type 3 or 4 letters and press enter before I realize focus has changed. You know what that means? I haven't read the message and I have pressed one of the buttons randomly without knowing.

I come from Mac OS 6. When they added some sort of multitasking to the system, they did it properly and the system would never move the focus away from the current window unless there was some sort of user input to do it.
It worked perfectly till Mac OS 9. I was very happy (I didn't know then that I was happy), but I was forced to move to windows. They have this problem with focus too. Then I moved to ubuntu cause I thought this sort of things (The Really Important Stuff) were a lot more polished than in windows.

But then I find the most annoying, stupid and important usability bug is present in Windows, Ubuntu and I heard in Mac OS X too. And probably other linux distributions as well.

This needs to be fixed. The front/current window must keep the focus no matter what. Only user input should move the focus away.

[Sense Egbert Hofstede (sense)]

We're discussing this issue on the Ayatana Discussion mailing list because it is something I would like to see fixed, but I would like to get some feedback from some other people before confirm this bug for the Hundred Papercuts project.

[Triqui (triqui)]

Sorry.
Why you set it to invalid and incomplete?
Let me know what I need to do, cause I really want to see this fixed.

Just a new and brief try to clarify.

I've checked on the internet and tried every setting I found (for metacity) but I cannot get the desired behavior. That is:
1. I have a window opened and lots of things going on in the background, I don't want any of them to move in front of the window I'm staring at.
   1.1. No matter whether or not I'm typing or clicking or interacting with it in any way.
   1.2 No matter whether I manually launched some app (if it took some time to open I don't care, I'll get back to it when I want. Now I'm busy staring at some other window) or it's some automatic process or some notification.

2. Number 1 is the most important for me. But I also think that when I launch an app or open a folder or open a new window in any way, the default behavior should be to move that one to the front (as long as I don't start working with some other app/window before the new one is completely open, as stated in the first point).

Please, let me know how I can improve this report to get the bug fixed. Or what else I can do to help fix it.

[Sense Egbert Hofstede (sense)]

Triqui:
Marking the bug as Invalid was an accident, I wanted to set the status to Incomplete, but must have selected the wrong status.

You've already provided us with all the information we need to consider this bug report. Thank you for that. Now I'm waiting for the responses of some people with more experience with usability on the mailing list to verify a few things and to make sure this really is a papercut. The fix for this bug could potentially have a noticeable impact on the way windows behave and therefore it should be properly discussed first. Since the people I'd like to get an answer from aren't subscribed to these bugs I've sent a mail to the Ayatana Discussion mailing list.

[Sense Egbert Hofstede (sense)]

I'm afraid it was decided this is not a valid paper cut and not something we want to fix this way. Not only is the coding and the testing (don't forget the testing for an issue like this!) that would be required to fix the bug too much to make the bug a valid papercut, but Mark Shuttleworth also indicated that he finds the current situation better than what a solution for this report would give us:
> It's definitely not a papercut :-)
>
> Personally, I think trying to prevent focus-stealing does more harm than
> good. If you do that, you end up with a LOT of suboptimal situations
> like windows opening in the background. So I'm +1 the current band-aid.

> Focus stealing *is* less of a problem than making all other window
> openings unpredictable.

You can find the whole discussion here: <https://lists.launchpad.net/ayatana/msg02424.html>.

I'm closing this bug as Invalid.

[Triqui (triqui)]

Thank you for your time and your info, Sense.

You have to excuse me cause I'm very new to linux and ubuntu. And I've been trying to get into reporting bugs but with so many projects and web pages and components and all that stuff, I'm still a bit unsure about what's the best place to report anything.

So, if this is not a papercut, would you be so kind to let me know what would be the best place to report this. Cause it's very annoying and I really thing there must be something that could be done to solve it.

One last thing. I just wanted to show you a link to a lot of complaints in the Brainstorm site about this behavior -> http://brainstorm.ubuntu.com/idea/400/
Look how many ideas marked as duplicated. And also look at the dates of the posts ranging from the begining of 2008 to today (only in this post, I haven't checked all the duplicates).

Thanks again.

[Sense Egbert Hofstede (sense)]

Triqui: Don't apologise! You've done nothing wrong by filing the bug here. It may not have been a valid paper cut in the end, but we cannot expect all our users to know exactly how the paper cut project works.

The best place to discuss this would be either the Ayatana Discussion mailing list, which you can subscribe to by joining the Ayatana Discussion team on Launchpad at <https://launchpad.net/~ayatana>, or Ubuntu Brainstorm. You already gave a link to an idea on Ubuntu Brainstorm, so you've already found that website.

I see that this is one of the first ideas posted on Ubuntu Brainstorm, so I think that you should start discussing this issue with some people and make sure you mention that idea when you do.

[Matthew Paul Thomas (mpt)]

This bug is invalid, because sometimes when a new window opens, you absolutely want it to take focus from whichever window had focus before. A simple example is launching an application: if you start a Web browser and it takes only two seconds to open, it would be frustrating if it wasn't focused when it did open.

The Metacity, Compiz, and kwin window managers each have a focus stealing prevention algorithm which tries to guess whether it's appropriate to focus a new window or not. As I wrote in bug 67476, if you have suggestions for improving this algorithm, I suggest you work with other interested people (such as those subscribed to the Brainstorm "idea") on a specification with a flow chart for how it should work. Include a description of how it would differ from the existing algorithm, and examples of how it would do better. If you don't know what the existing algorithm is, that should be your first step. Once you're done, posting to the Ayatana list would be a good way of getting your specification reviewed.

[Triqui (triqui)]

Ok, thanks. I will.
But I think you haven't read my posts here.

First. If I have a window opened and it's focused I don't want any other window to move in front, no matter whether I'm typing or interacting with it or not (maybe just reading something).

Second. If I do something to open a new window, that one should be focused. You are right. But, if after I launched that window, I click on some other window, the newly selected window should get the focus and keep it. No matter if the window I just launched was already opened or still opening.

[Triqui (triqui)]

It is better written here:
http://git.gnome.org/browse/metacity/tree/doc/how-to-get-focus-right.txt
"
  1) If the window takes a while to launch and the user starts
     interacting with a different application, the new window should
     not take focus.
  2) If the window that will appear was not launched by the user
     (error dialogs, instant messaging windows, etc.), then the window
     should not take focus when it appears.
"

This is want I want. The thing is that I cannot get it working.

[Triqui (triqui)]

Wow, now, after all this time I found this bug -> https://bugs.launchpad.net/compiz/+bug/455241
Which seems to be getting a little more attention.
I had used Ubuntu for a couple of months only when I reported this bug, but I swear I searched a lot to see if this bug had already been reported. And now I find that was the case.
Sorry.