Bug 319075

Comment 1 Prakash Rangaraj 2010-07-07 02:39:17 EDT

I think that the enablement of a command should be determined only by the handler. If we do it at the contribution level as you ask, then it will be confusing. Like the Copy/Paste will be enabled in the toolbar, but could be disabled in the menu/elsewhere. 

What is your usecase?

Comment 2 Erdal Karaca 2010-07-07 06:09:57 EDT

In a rcp where the standard workbench actions are not provided, e.g. the user cannot use Open Perspective to switch to another perspective, one has to provide another way to accomplish this task.
That ist not that hard because there are already predefined command, e.g. the showPerspective command.
Now, I want this menu item (that will call showPerspective) to be visible, but will be disabled when the user has no access to it.
The problem being the re-usibility of that command: its enabledWhen expression cannot be reset or modified. I would have to define my own showPerspective command that is ready for checking access.
Just remember that there are hundreds of re-usable commands...

Now, if a "guest" user would have minimal access to the actions, the UI would be rather empty. If there would have been disabled items, he would just know that those disabled items would have been executable if he had access rights...

If adding enabledWhen to menu contributions is too confusing (I agree :-), then,
there should be at least a way to bind additional enabledWhen expressions to a command/handler.

Comment 3 Erdal Karaca 2010-07-09 07:05:40 EDT

One thought, though:

If we consider a menu contribution to be an "instances" of a command, then that enabledWhen must *really* belong to that specific menu contribution.
If the enabledWhen of the command's handler is extended, then this will affect *all* command instances. E.g.: if there are 3 "Switch Perspective" buttons, then, all 3 will be disabled if their corresponding handler is disabled.
Yet, I just want button 2 to be disabled without affecting the other two.

Implementing this will break api or at least the api would have to be extended, e.g.

org.eclipse.ui.menus.IContributionRoot.addContributionItem(IContributionItem, Expression)

would have to take a new Expression parameter to handle an additional enabledWhen condition...

Comment 4 Paul Webster 2010-07-09 07:48:05 EDT

(In reply to comment #3)
> One thought, though:
> 
> If we consider a menu contribution to be an "instances" of a command, then that
> enabledWhen must *really* belong to that specific menu contribution.
> If the enabledWhen of the command's handler is extended, then this will affect
> *all* command instances. E.g.: if there are 3 "Switch Perspective" buttons,
> then, all 3 will be disabled if their corresponding handler is disabled.
> Yet, I just want button 2 to be disabled without affecting the other two.
> 

this breaks the 3.x architecture.  Enablement is a state of the command, of which there is only one per application.  It's either enabled or disabled (and the menu contributions must reflect that).

i.e. you can't make just this toolitem disabled, as they keybinding would still work.

The notion of command/handler state localized to a view won't work in 3.x.  But it does work in 4.0, since enabled is a question asked the command in a context, not a state of the command/handler itself.

PW

Comment 5 Prakash Rangaraj 2010-07-29 05:37:04 EDT

I guess this would be a wont-fix.