On Apr 24, 2013, at 10:30 AM, Norbert Hartl <norb...@hartl.name> wrote:
>
> Am 24.04.2013 um 10:00 schrieb Goubier Thierry <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.
> 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.
>
But aren't *context* menus named like that because they depend on the context?
If I get a context menu for a class or a method in the panes above, they are
different, too.
Marcus
