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

["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?