Re: [Ayatana] Middle-click on indicators

[Remco <remco47@xxxxxxxxx>]

On Thu, Apr 15, 2010 at 09:48, Mark Shuttleworth
<mark.shuttleworth@xxxxxxxxxxxxx> wrote:
> On 15/04/10 07:42, Chow Loong Jin wrote:
>> You are missing my point. I am not disputing the decision to use menus
>> as a model (like you said, that is for a different discussion). I am
>> saying that we should not keep ourselves locked to menus and menus
>> alone, rejecting all other features for the sole purpose of being a menu.
>
> Agreed.
>
> The question is not really one of principle, it's one of taste.
>
>> An indicator is not a menu, no matter how much you may attempt to model it after
>> a menu, and it serves a different purpose from that of the menus you are talking
>> about.
>>
>> For example, a normal menu has many actions, out of which only a small subset of
>> which are very frequently used. These would be abstracted out into toolbar icons
>> (one-click access), e.g. Back, Forward, Refresh, New Tab, etc, and/or given
>> keyboard accelerators, which can then be triggered as long as the window the
>> menu belongs to has focus.
>>
>> Now take a look at our application indicators. Each application indicator has
>> many actions, and most of them will have *one* frequently used one, i.e.
>> "Show/Hide Application".
>>
>> We cannot assign these actions keyboard shortcuts, because the "window" that
>> owns these menus is the panel, and it does not make sense to have to focus the
>> panel in order to trigger these keyboard shortcuts. An alternative would be to
>> use global keyboard shortcuts, but I do not foresee that ending well.
>>
>> We do not have a toolbar to abstract these actions out into. But wait! These
>> application indicators are *already* icons. They look and act more like toolbar
>> buttons that have menus (much like the Back/Forward history dropdown menu in
>> Firefox) than actual traditional text-based menus that you see at the top of
>> each window. So, why would it not make sense to provide one-click access to the
>> aforementioned frequently used action?
>>
>> The following point has probably been raised before and beaten to death before,
>> but the time taken to aim for one application indicator icon, click for menu to
>> open, then aim *again* for the menu item needed is significantly more than the
>> time it takes to aim for the application indicator icon and click *once*. I
>> would say that the former case would result in slightly less than twice the
>> time, and approximately twice the effort taken compared to the latter case.
>>
>
> I don't fault your logic. But I can disagree with your taste. I think it
> would be crass if we encouraged every app indicator to have a secret
> bunch of behaviours associated with specific clicks. I know that opening
> up a possibility like this results in a mess - an unusuable mishmash of
> secrets.

There is precedent for this in Windows. Tray menus can have a
bold-faced item, which is activated on double click or middle click.
It's one of the few things that fairly consistent among Windows' tray
icons. This is also consistent with desktop icons, which have one
default action: open. Double clicking or middle clicking on the icon
opens the file.

We could do the same in the menus: make one action the default action,
and that will be the action that happens on double click (or middle
click). By making the item bold, you have some form of discovery.

-- 
Remco