← 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”

 

> So, we've gone as far as ignoring raise requests 0.5 seconds after the
> last release event. But what about one whole second after? Two seconds?
> Three? Five? Ten?

You're still looking at length of time, which I don't think is
relevant. We could define this length of time, though, as exactly the
same as the length of time between the action that spawned the new
window (e.g. clicking the icon) and the window opening.

>>> 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».
>
> So every launcher should be responsible for sending a signal to the
> window manager to say "I've just launched something, please unfocus
> whatever you had focused"?

Almost—it should only be able to say “please unfocus *me*”. (Or the
window manager should only respond to requests to unfocus the
requesting window. Same UX.)

If the app to be launched already has a window, the launcher could
throw focus to that window instead of to «nothing».

> How is the launcher supposed to know whether the program it is launching
> will open any windows at all?

Good point.

(Arguably, launching *any* app should add *some* affordance to the
current over-all UI—perhaps just an indicator.)

However, I suggest the launcher doesn't need to know this. If no new
window is opened, we end up with «nothing» focused after the app is
launched. This is OK. The user can just click a window to begin
interacting with it.

*****

So far we've only discussed new windows, but existing windows could
request focus for themselves too. This would be the equivalent of the
current RequestsAttention system; if «nothing» is focused, the WM
could grant focus immediately. Windows (e.g. launchers or commands
that throw focus to non-modal dialogues) could also send focus to
another existing window.

As a non-programmer I could imagine a function throwfocus(target),
which accepts 0 or 1 parameters and could be called by any window at
any time. When there's no parameter, calling this function requests
that focus should go to «nothing». When a window is specified as the
parameter, the function requests that focus should go to that window.
The target window can be the same as the window calling the function.

* If the window calling the function is currently focused or if
«nothing» is currently focused, focus would switch to the target
immediately.
* If the window calling the function is not focused and the target is
a window, the target would effectively get a RequestsAttention flag.
* If the window calling the function is not focused and the target is
«nothing», nothing happens.
* If the target is currently focused, nothing happens.

The rules:
0. The user can focus any window.
1. The focused window can give focus to any existing window or to «nothing».
2. When «nothing» is focused, any window can give focus to any window
including itself.
3. When a window is focused, an unfocused window can request attention
for any window.
4. When a new window opens and «nothing» is focused, the new window
immediately (automatically) gives focus to itself, and appears
frontmost.
5. When a new window opens and another window is focused, the new
window immediately (automatically) requests attention for itself, and
appears behind all other windows.

“Window” above can be taken to read “application” if app-based
switching is preferred.

I considered raising attention-requesting windows so that they were
just behind the focused window; but this would be disruptive if a
maximised window requested attention while the user was using two
windows side-by-side. The only logical place to put new unfocused
windows, therefore, is at the back.



References