Re: right click *in* a menu

[Christian Dywan <christian lanedo com>]

Am Tue, 7 Dec 2010 07:16:25 -0500
schrieb Paul Davis <paul linuxaudiosystems com>:

> On Tue, Dec 7, 2010 at 2:44 AM, Martin Nordholts <enselic gmail com>
> wrote:
> 
> > The problem to be solved is not "How do we modify GTK+ to make it
> > as easy as possible to invoke nested menu items several times in a
> > row in Ardour", but "How can we redesign the Ardour UI so users
> > don't have to invoke nested menu items several times in a row to
> > use the software".
> 
> This is an overly focused and specialized view of the question.
> 
> The major distinction between a menu and a dialog is that menus
> typically *do* close after a click, whereas dialogs generally require
> a series of 0,.N clicks on possible action proxies, and then one or
> more confirmative steps to actually close the dialog.
> 
> So the question is whether there is a place for menu semantics in
> which only an umodified left click closes the menu, and some other
> click still activates the item but leaves the menu open, OR whether
> the claim is that any interaction with a presentation of a set of
> multiple actions should be done via a dialog with an explicit close
> operation.
> 
> We *could* push all the operations in the current region context menu,
> for example (right click on a region -> Select region name -> menu
> with 20+ items) into a dialog for that region, but it would 1 mouse
> motion+drag or the use ctrl-w to every single action activation for
> anything on that menu when you only do a single action.

Space on tick or radio leaves the menu open.

I think for a state change, it would be sensible to have an analogous mouse-based action. A right-click could be just that.
Anything that goes beyond toggling would be a bad distortion of menu semantics in my opinion.

And keep in mind this is undiscoverable, not counting accidents. You should document it if it is an important part of the common workflow.

-- 
ciao,
    Christian