unity-design team mailing list archive

[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.
>