unity-design team mailing list archive

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

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

> Den 28. sep. 2011 11:24, skrev Stefanos A.:
>
>  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.
>>
>>  Unacceptable delay? I estimate a delay of about 20ms. Perhaps you've
> misunderstood something?


Where did you pull this 20ms estimation from? Any references? As you said, "
those kinds of unsubstantiated claims carry very little weight with me  ."

(Your number is wrong by an order of magnitude, but I'd really love to hear
how you arrived at 20ms.)



>  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.
>>
>>  It would never make sense to cancel those events. That's something that's
> been bugging me about Gnome for many years, that if you clicked the wrong
> menu entry, then it was not possible to cancel it. You would have to run
> that application, close it, open the menu and then start the right
> application. If the action was initiated on release, then you could've
> simply pressed esc to cancel. It's seriously annoying to be unable to cancel
> launching LibreOffice because I hit 5 instead of 4. I should be able to hit
> esc before I release and prevent it.


Off-hand, this looks difficult to implement, because the Launcher does not
have keyboard focus and will not (cannot) receive the Esc key without bad
side-effects. It's an interesting idea but doesn't really belong to this
thread.


>
>  (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).
>>
>
> I am unable to verify that claim, but I've been told that many people gets
> kidnapped by aliens too. Those kinds of unsubstantiated claims carry very
> little weight with me. But you're talking about consistency? When you use
> the mouse, then the entries are not activated by press, but by release, and
> only if you don't press and hold for long periods of time, like more than
> one second. When you use the keyboard, it is opposite. Why is that a good
> idea?
>

My anecdote came from a reputable dead-tree IT magazine back from 2006, in a
language you are unlikely to be proficient in. Google results in too much
noise, so just take it or leave it. (However, you can verify the claim very
easily if you have access to Office 2007 and 2003 or LibreOffice).

In any case mouse is completely different than the keyboard. All Gnome
keyboard shortcuts act upon key press (Alt+F4, Ctrl+W, ...) and applications
are should not mess with that. There is no clear guideline for mouse press
vs release, so Unity is in gray waters there (most Gnome mouse navigation
acts in mouse press but I can see where the Unity developers are coming
from. I'd certainly prefer Shift+Click for moving Launcher items, instead of
drag&drop).