unity-design team mailing list archive

["Stefanos A." <stapostol@xxxxxxxxx>]

2011/9/28 Jo-Erlend Schinstad <joerlend.schinstad@xxxxxxxxx>

> Den 27. sep. 2011 16:39, skrev David:
>
>  I like the idea, but wouldn't it mean coding a delay before Unity actually
>> launches the program?  Otherwise, how will it know whether you want to
>> launch or just move the icon?
>>
>
> No, it wouldn't, because you wouldn't actually initiate anything until the
> buttons were released. From a users point of view, this shouldn't change
> anything. If you press and hold super+2, then nothing happens, except that
> the launcher stays visible. When you release 2, then you switch to the
> second entry.
>
>
I just tried and the Launcher currently activates on key press, not release.
Super+2 activates without releasing the key.

Change the key press to key release would indeed introduce an unacceptable
delay. I have already filed bugs on Unity for things that are activated on
release rather than press, like the BFB (now Dash button - it's not movable
so there's absolutely no reason to activate on release). These things make
Unity feel slow, even though it isn't. Gratuitously introduce more delays is
not the way to go.

Especially since you can add a different shortcut for reordering, such as
Shift+Super, and keep *both* actions on key press. In fact, that's how the
workspace switcher works: Control+Alt is activated on key down, as is
Shift+Control+Alt. Simple, symmetrical and no additional delays.

(Interesting anecdote: many reviewers commented that Office 2007 was much
faster than Office 2003 because its right-click menu activates on mouse down
and not mouse up. This was actually made a big deal back then! I'm bringing
this up to highlight that this is not a non-issue - there is measurable
speed difference that affects user satisfaction).