← Back to team overview

unity-design team mailing list archive

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

 

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.

Follow ups

References