I can add the entrance in Nautilus menu today, I didn't think in that and it can be cool. I want to put some contextual information about the selection.
I think that on Friday I can make the slice. 2013/4/24 Goubier Thierry <thierry.goub...@cea.fr> > Le 24/04/2013 10:29, Norbert Hartl a écrit : > >> >> Am 24.04.2013 um 10:00 schrieb Goubier Thierry <thierry.goub...@cea.fr >> <mailto:thierry.goub...@cea.fr**>>: >> >> >> Maybe we can make a destination between two cases: >>>> >>>> 1) cursor is placed somewhere. Here people are interested in >>>> suggestions. The context menu like it is now makes sense >>>> (I would add one entry for the suggestions, in addition to the >>>> shortcut) >>>> >>>> 2) The user *selected* something explicitly. Here I think we should show >>>> a modified context menu that only has those things >>>> the make sense on the selection. Nobody want to "Debug it" a >>>> variable, or "print it" a syntactically invalid selection... >>>> >>> >>> Hum, this one looks cool. The default action menu is quite long >>> (debugIt, exploreIt, etc...) and making it shorter is a nice touch. >>> >> >> Yes, but unfortunately it doesn't work that way most of the time for the >> unexperienced.. Learning a UI means knowing where things are. A changing >> context menu mostly leads to confusion because you struggle finding >> things you saw before. Those things only make sense if you're already >> comfortable with the UI and the environment. I think that is one reason >> we menu entries are often just greyed out. This way you have the >> orientation because the menu is of the same shape and by seeing greyed >> out stuff you can immediately learn that some menu entries do not make >> sense in this context. >> > > Yes. You're right for that, however, the issue is that the base menu is > too long from an UI point of view (no more than 7 +/-2 elements). The > minimum you get on a code pane (when you build the menu yourself properly, > as I do for the AltBrowser) is 12 commands: (accept, cancel, undo, redo, > cut, copy, paste, do it, print it, inspect it, explore it, debug it) with > the last five greyed out if you haven't selected anything. > > It looks hard to decrease to a more reasonable number - especially the > five ways of executing some selection. > > Suggestions are very much selection or cursor dependent; and there will be > a lot of them, so greying out will be unmanageable. I don't think that > having a menu long and deep, with just a few entries non-greyed out, will > be usable. And given that the suggestions are selection/cursor based, > guessing when a greyed entry will activate itself will be an interesting > exercise for a newcomer :) > > > Maybe the way it can work is to have this as an option. First grey out >> things and the expert can switch them off to make disabled entries >> invisible. >> > > Or have a suggestions submenu which restrict changing entries to a subset > of the menu: Main, essential items are few and fixed; changing things are > restricted to a specific submenu. > > > But then I'm far from being an UI/UX expert. >> > > Me neither. I worked in that field a long time ago, but that's all. > > Thierry > > Norbert >> > > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des Systèmes Temps Réel Embarqués > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > >
