Community
Participate
Working Groups
Currently IAction has a setEnabled() method which allows me to programmatically control the enablement of an Action rather than relying on the XML to determine this. However, there is no setVisible() type method to programmatically control visibility as an alternative to the XML approach. I looked at the actionExpressions document as it relates to visibility, but it doesn't really help in all cases. Specifically, since I'm dealing with the Java Packages view, it's quite conceivable that the objectState attributes which JDT provides for their elements are insufficient and unrelated to the specific information needed for my particular plugin to make visibility of my actions work as desired. And as IActionFilters are provided by the view itself, they don't seem to be the answer either.
If you require this support in the 2.0 version of eclipse please reopen this defect.
Reopen to investigate
One reason why there is no support for this is because it will confuse the user when a menu item "disapears" on them. Until your plugin is loaded, the platform would show your action in the menu and the user would see it. Then the user does something in the UI (not having to do with your action) that causes your plugin to be loaded. Now when the user looks in the menu, your action would be gone (because your delegate was given the chance to update the action when the plugin was loaded). Did you have any ideas how you envisioned this to work? At the moment, I'm not sure this is something we want to add API for.
I originally opened this request because I was attempting to support the following: our plugin supports various debugging options (ie, via - debug "file:d:\.options") which includes the addition of several actions to menus. If it were my own view, I could construct a context menu to include or not include these actions based on the option settings. However, the menu I needed to affect was in the Package Explorer view. As it stands, the control over visibility via xml is too limited to address this need and hence my additional menu choices are always visible whether debug options have been specified or not. I was merely seeking a programmatic equivalent to what could be done in a limited way via the xml. And I noted that enablement was already controllable both with xml and programmatically, so this seemed like a symmetrical request. I think I understand your point about the possible confusion for the user, but honestly it's no less confusing than what already occurs for enablement in my opinion. As it stands now, actions will initially appear enabled and it's not until the user attempts to access them that it is determined they are not applicable. So I pick an enabled action, it tells me I can't do that right now, and if I go right back to the menu, it's now disabled. Personally, that strikes me as confusing. And as a result of that innocent action, I've now activated that action's plugin and who knows what the bottom line result of the plugin being activated is (ie, builders, resource change listeners, etc, etc), all of which could have been averted if the menu choice was simply not there or disabled. Ultimately I would like to be able to have some small snippet of code that could be executed to determine visibility and/or enablement but doesn't result in full blown plugin activation (no small request, I understand). But for now, all I was looking for was a visibility equivalent to IAction.setEnabled().
Reassigning to Platform-UI-Inbox (I left IBM 18 months ago..)
Moving Dougs bugs
Assigning to component owner PW
With menu contributions you can tie your visibility to contexts, object properties, or even action sets. Available as part of the command framework in 3.3. PW
