unity-design team mailing list archive

["frederik.nnaji@xxxxxxxxx" <frederik.nnaji@xxxxxxxxx>]

Hi mpt,

this ancient problem is still not really resolved, is it?
By now we are on Compiz by default, and that's where i would want the
problem fixed.
Especially envisioning the possibility of Compiz also working without 3d
accelleration in the future.

Resolving it could presumably also help clear some questions in Unity.
Allow me..

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

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Frederik Nnaji wrote on 21/06/10 16:44:
> >
> > On Mon, Jun 21, 2010 at 10:00, Matthew Paul Thomas <mpt@xxxxxxxxxxxxx
> >...
> >> Greg K Nicholson wrote on 29/05/10 02:05:
> >>>
> >>> 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.
>
> So how do you define "activity"?
>
> If the mouse button is actually *down*, or a keyboard key is actually
> *pressed*, when a window from another application requests a raise, it
> should not be raised. That much is obvious (and seems to be a bug in
> current Metacity).
>
> But what if you released the mouse button, or the keyboard key, 0.1
> seconds before the other window requests the raise? You're quite likely
> to be in the middle of a double-click or of typing a word. So the window
> shouldn't be raised then either.
>
> Ok, so what if you released the mouse button, or the keyboard key, 0.5
> seconds before the other window requests the raise? The same applies,
> just a bit less certainly.
>
> 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?
>

This could be quite simple:
Imagine you're writing your essay in your favourite Word Processor, typing,
clicking, panning and zooming, whatever.
Now there's this word you couldn't find in the Word Processor's built-in
dictionary, so you need to open your favourite Browser to find it online.
Now there are precisely 2 things that can happen:
1) the browser starts up immediately, i.e. before you get the chance to
interact with anything else
2) the browser starts up delayed, i.e. you get enough time to start typing,
clicking or otherwise interacting with another app, before browser's launch
is complete

*now*, in case 1 we have all the conditions satisfied for arrogantly raising
the browser window, because since the menu-interaction (clicking the
browser's launcher) and *now*, no human-computer interaction has taken place
anywhere else (disregarding eye movement for now..).
For case 2 the obvious sequel is clear: after clicking the browser's
launcher in e.g. Unity's Dock, i started interacting with something else,
i.e. i gave my human focus to another application, window, document or
whatever one would want to call that.. NOW it would be focus-stealing, to
pop up the browser window on top of the Z-Stack in my face, no matter if the
last keystroke is 0.5 sec, 1.0 sec or 25.9 sec ago. Simply because i decided
to focus another application *after* i decided to launch the browser.

I think this is more like the conditional logic you were asking about.

So all depends on what the user does and in what sequence of action.
If the computer had a way of knowing better what i wish to focus now, i
would expect it to act on that knowledge. But the only knowledge it has is
in what sequence (when) i performed the steps of interaction, so it should
be able to at least honor *that*.

What about the app i launched?
It should either have a throbber while it's loading, or a progress
animation. Either way, it is in the interest of the user that a continuous
visualisation of progress or activity is present in or on every
representation of the app whose launch i requested. If i decide to focus
something else in the meanwhile, it is only natural to assume that i want to
be notified once the app i requested is ready for use.
I want to be notified, not interrupted or thrown out of typing. The proposed
"morphing windows" could be a solution here. It's just that they should not
get keyboard focus or anything, they should only be on top of the stack and
preferrably not fully opaque and in the middle of the screen. Persistent
until either dismissed or confirmed.

What do you think?