Community
Participate
Working Groups
With contribution items it is possible to enable/disable command handlers depending on the state of the selection in the current active workbench part. However, when a contribution item is added to a view menu and this view is not active then the menu item will be enabled/disabled depending on the selection in another workbench part. This is confusing to the user. It seems to be necessary to bind the menu contribution item only to the selection provider of the view it belongs to. The required behaviour is possible with the extension point org.eclipse.ui.viewActions. However this extension point is deprecated as of Kepler. Please enhance the definition of contribution items such that they can be enabled/disabled depending on properties not of the active part but of the owning part. For clarification of this RFE see messages in the Eclipse Forums and on Stack Overflow: http://www.eclipse.org/forums/index.php/mv/msg/544331/1131076/#msg_1131076 http://stackoverflow.com/questions/15475397/enabling-contribution-items-by-different-selections
This is an enhancement that we want but don't have the cycles to look at. With the move to Eclipse4, tool items check their enablement in the context they exist in. So a toolitem in a view will look to the active IEclipseContext leaf from its own view, and in a different view that uses the same command that tool item will look to its own active leaf. The next step is that contributions through org.eclipse.ui.handlers need to be enhanced so that they can exist at any level of the model (application, window, or part). Right now they just exist in the part level. PW
(In reply to Paul Webster from comment #1) > window, or part). Right now they just exist in the part level. Sorry, that should read: "Right now they just exist in the application level, so there's only one state for a command for the entire program" PW
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag.
