Re: right click *in* a menu
Hi! well, i think it implies being able to use a menu like a dialog window. Exactly. If you need the menu to behave like a dialog box, use a dialog box. Hm, why are you so dogmatic? Normal user uses _left_ click for opening the menu and _left_ click chooses an menu iterm and closes the menu. So it is quite usefull to reuse _right_ click for other task, such as for selecting multiple items out of the menu at once. Well, at least for galeon, it brings up context menu _for the menu item_. (It for example allows you to delete bookmark). I'd very much like such menus to be in all application, enabling me to set keyboard accelerators. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: right click *in* a menu
On Tue, Dec 7, 2010 at 2:44 AM, Martin Nordholts ense...@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. --p ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: right click *in* a menu
Am Tue, 7 Dec 2010 07:16:25 -0500 schrieb Paul Davis p...@linuxaudiosystems.com: On Tue, Dec 7, 2010 at 2:44 AM, Martin Nordholts ense...@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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: right click *in* a menu
On Tue, Dec 7, 2010 at 8:12 AM, Christian Dywan christ...@lanedo.com wrote: 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. RiscOS didn't think so, all those years ago :) And keep in mind this is undiscoverable, not counting accidents. You should document it if it is an important part of the common workflow. context clicking is equally undiscoverable and has an honorable history and usage. just sayin' - i have very little skin in the game. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: right click *in* a menu
Am Tue, 7 Dec 2010 09:38:55 -0500 schrieb Paul Davis p...@linuxaudiosystems.com: 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. RiscOS didn't think so, all those years ago :) I suppose I'd need to actually try it in a situation where it is useful. I've never used RiscOS. And on all other systems I can think of a menu is distinctly floating and temporary. And keep in mind this is undiscoverable, not counting accidents. You should document it if it is an important part of the common workflow. context clicking is equally undiscoverable and has an honorable history and usage. I'm painfully aware. But it is so universally available that advanced users usually know about it even if they switched operating systems. -- ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: right click *in* a menu
On Tue, 07 Dec 2010 at 16:48:19 +0100, Christian Dywan wrote: I suppose I'd need to actually try it in a situation where it is useful. I've never used RiscOS. And on all other systems I can think of a menu is distinctly floating and temporary. RISC OS really needed this feature, where many GUIs don't: - it didn't have multiple menus just below the titlebar like Windows, or at the top of the screen like Mac OS - instead, every menu was contextual, starting with a middle-click (the equivalent of right-clicking in most modern GUIs) - the menus were often rather deeply nested, partly as a result of moving the entire main menu structure onto a single context menu (e.g. middle-clicking the document window in a word processor had to make most of the app's functionality available in one menu) I personally don't think a well-designed GNOME (or for that matter KDE, Windows or Mac) app should need this feature, because those two factors don't apply in our environment. I'm not an interaction designer or a UI hacker, though... There's some good background here: http://telcontar.net/Misc/GUI/RISCOS/#menus Regards, S ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
right click *in* a menu
Some users of my software raised this issue in the last 24hrs: - I still call `!' `pling'... I'm still missing the extremely handy RiscOS feature that right-click on a menu allowed to make a selection without closing the menu. Such a thing in GTK would have me saved hours of re-opening nested menus in Ardour. Ciao, I'm wishing for that as well all the time. I wonder who came up with the idea that there's only ever one thing you want to do in a menu. Didn't know anyone was clever enough to implement something as complex as don't close menu if right-clicked or don't close if modifier is pressed when menu-item is clicked. It's one of those obvious user interface doh's. -- has this ever been considered? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: right click *in* a menu
On Mon, 2010-12-06 at 13:34 -0500, Paul Davis wrote: Some users of my software raised this issue in the last 24hrs: - I still call `!' `pling'... I'm still missing the extremely handy RiscOS feature that right-click on a menu allowed to make a selection without closing the menu. Such a thing in GTK would have me saved hours of re-opening nested menus in Ardour. Ciao, I'm wishing for that as well all the time. I wonder who came up with the idea that there's only ever one thing you want to do in a menu. Didn't know anyone was clever enough to implement something as complex as don't close menu if right-clicked or don't close if modifier is pressed when menu-item is clicked. It's one of those obvious user interface doh's. For check and radio buttons, you can hit space to toggle them without closing the menu. - Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: right click *in* a menu
On Mon, 6 Dec 2010 13:34:36 -0500, Paul Davis wrote: I'm wishing for that as well all the time. I wonder who came up with the idea that there's only ever one thing you want to do in a menu. Didn't know anyone was clever enough to implement something as complex as don't close menu if right-clicked or don't close if modifier is pressed when menu-item is clicked. Am I the only one who thinks that having a menu you don't want to close after making a selection means a badly designed UI? -- Jernej Simončič http://eternallybored.org/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: right click *in* a menu
2010/12/6 Jernej Simončič jernej|s-gm...@eternallybored.org: On Mon, 6 Dec 2010 13:34:36 -0500, Paul Davis wrote: I'm wishing for that as well all the time. I wonder who came up with the idea that there's only ever one thing you want to do in a menu. Didn't know anyone was clever enough to implement something as complex as don't close menu if right-clicked or don't close if modifier is pressed when menu-item is clicked. Am I the only one who thinks that having a menu you don't want to close after making a selection means a badly designed UI? well, i think it implies being able to use a menu like a dialog window. i'm not convinced that this is obviously a good thing, but its not obviously bad either. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: right click *in* a menu
On Mon, 6 Dec 2010 14:33:21 -0500, Paul Davis wrote: well, i think it implies being able to use a menu like a dialog window. Exactly. If you need the menu to behave like a dialog box, use a dialog box. i'm not convinced that this is obviously a good thing, but its not obviously bad either. IMHO, it's bad - menus are intended to make a quick choice - run this command, switch to that mode of operation - they're not intended to configure the program. -- Jernej Simončič http://eternallybored.org/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: right click *in* a menu
On 12/06/2010 08:03 PM, Jernej Simončič wrote: On Mon, 6 Dec 2010 13:34:36 -0500, Paul Davis wrote: I'm wishing for that as well all the time. I wonder who came up with the idea that there's only ever one thing you want to do in a menu. Didn't know anyone was clever enough to implement something as complex as don't close menu if right-clicked or don't close if modifier is pressed when menu-item is clicked. Am I the only one who thinks that having a menu you don't want to close after making a selection means a badly designed UI? I was thinking the same thing. In my world, such a menu future would merely be a workaround for a proper UI. Just like tear-off menus. / Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: right click *in* a menu
On Mon, Dec 06, 2010 at 08:38:34PM +0100, Jernej Simončič wrote: On Mon, 6 Dec 2010 14:33:21 -0500, Paul Davis wrote: well, i think it implies being able to use a menu like a dialog window. Exactly. If you need the menu to behave like a dialog box, use a dialog box. Hm, why are you so dogmatic? Normal user uses _left_ click for opening the menu and _left_ click chooses an menu iterm and closes the menu. So it is quite usefull to reuse _right_ click for other task, such as for selecting multiple items out of the menu at once. I don't see any reason, why a dialog box must be used if for most users the menu is optimal way (because they select only one item most the time) and the minority may use it with the right click in a more powerfull way. -- Petr Tomasek http://www.etf.cuni.cz/~tomasek Jabber: but...@jabbim.cz EA 355:001 DU DU DU DU EA 355:002 TU TU TU TU EA 355:003 NU NU NU NU NU NU NU EA 355:004 NA NA NA NA NA ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: right click *in* a menu
On 12/06/2010 11:37 PM, Petr Tomasek wrote: On Mon, Dec 06, 2010 at 08:38:34PM +0100, Jernej Simončič wrote: On Mon, 6 Dec 2010 14:33:21 -0500, Paul Davis wrote: well, i think it implies being able to use a menu like a dialog window. Exactly. If you need the menu to behave like a dialog box, use a dialog box. Hm, why are you so dogmatic? Normal user uses _left_ click for opening the menu and _left_ click chooses an menu iterm and closes the menu. So it is quite usefull to reuse _right_ click for other task, such as for selecting multiple items out of the menu at once. I don't see any reason, why a dialog box must be used if for most users the menu is optimal way (because they select only one item most the time) and the minority may use it with the right click in a more powerfull way. 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. Like you though, I strongly doubt dialog boxes will be part of an optimal solution. / Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: right click *in* a menu
On Tue, 2010-12-07 at 08:44 +0100, Martin Nordholts wrote: On 12/06/2010 11:37 PM, Petr Tomasek wrote: On Mon, Dec 06, 2010 at 08:38:34PM +0100, Jernej Simončič wrote: On Mon, 6 Dec 2010 14:33:21 -0500, Paul Davis wrote: well, i think it implies being able to use a menu like a dialog window. Exactly. If you need the menu to behave like a dialog box, use a dialog box. Hm, why are you so dogmatic? Normal user uses _left_ click for opening the menu and _left_ click chooses an menu iterm and closes the menu. So it is quite usefull to reuse _right_ click for other task, such as for selecting multiple items out of the menu at once. I don't see any reason, why a dialog box must be used if for most users the menu is optimal way (because they select only one item most the time) and the minority may use it with the right click in a more powerfull way. 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. Like you though, I strongly doubt dialog boxes will be part of an optimal solution. User configurable toolbar/control panel could be a solution ? Just a tentative idea, with advanced editing tools (3d modelling softwares being good examples), you generally want to let the user tailor their workflow to their own specific needs (different people use the software to achieve different tasks, with a gazillion options and features it's hard to guess which tasks are good candidates to use up screen real-estate in a toolbar). Maybe something as simple as implementing DnD from a menu-item to a drop area in the toolbar/control panel is a good solution (then you save the actions in some session data). Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
