Re: [Ayatana] Papercut or not? Bug #495403 in One Hundred Paper Cuts: “Do not raise windows or dialogs without user input”

[Frederik Nnaji <frederik.nnaji@xxxxxxxxx>]

i need to add this:

after launching an app from whatever menu, there are two directions to move interaction into:

* towards the loading app

* away from the loading app.

* there is no neutral behaviour..

* A progress window should be displayed as a placeholder, until an app finishes loading.

Now we have synchronous behaviour between the user's launch-action and the window manager's feedback on the other hand. Now we can decide what to focus, without further reasoning.

If i dismiss the progress window now, i do it consciously. No need to break my focus any further with anything, except a notification bubble after the app i once launched has finished loading and is ready.

On Mon, Jun 21, 2010 at 17:44, Frederik Nnaji <frederik.nnaji@xxxxxxxxx> wrote:

On Mon, Jun 21, 2010 at 10:00, Matthew Paul Thomas <mpt@xxxxxxxxxxxxx> wrote:

Greg K Nicholson wrote on 29/05/10 02:05:

>> So when should the window manager switch from assuming

>> you want a new window focused, to assuming you don't?

>> After five seconds? Ten? Twenty?
>
> It shouldn't be timed.

yes, exactly. It requires context aware logic, rather than an unflexible countdown.

> I suggest that if you haven't had time to focus another window (i.e.
> if you haven't started doing something else), focus the new window. If
> you've focused another window, the new window should open in the
> background.

So how do you define "started doing something else"?

Something else is mouse and/or keyboard activity in an other application.

* Honor the user's choice of focus

If you want to raise a window, while the user is interacting with another window, you can be sure you're gonna break his focus.

 

> The window manager doesn't need to know what launched the window. The
> focus state of the new window should only be based on what's focused
> when the new window opens. The launching app can then affect the new
> window's focus indirectly by throwing focus to «nothing». If «nothing»
> remains focused by the time the new window opens, focus the new
> window. If something is focused when the new window opens, it keeps
> focus.

+1

honor the user's choice of focus.

NEVER break his focus, unless your focus-breaker is a critical alert.

User is being exposed to a dysfunctional application window which is not ready for interaction.

First of all, this shouldn't be possible.

The application window should not be displayed until it is 100% ready for user interaction.

Instead, a progress window should be displayed while the application window is loading.

We have been discussing the usage of informative splash screens that give information on the progress of the the application loading.

In the OpenOffice.org case, that would mean the previously focused

window would remain focused for about 30 seconds after you launched
OpenOffice.org, *then* become unfocused as soon as OO.o became able to
do anything.

yeah, OOo should rather set the hint flag on its window once it finishes loading, with a message:

"i am ready now". The notification system can listen in via dbus or an equally potent IPC method, then display a decent notification to the user:

"OOo is now ready" & [switch-to button]

Now it is up to the WM to afford to the user a comfortable way of switching to the correct application, honoring his current choice of focus, not breaking the user's intended path of action.