Community
Participate
Working Groups
The dynamicPopupMenuExtensions seems to be obsolete. It should be possible to achieve the same via org.eclipse.ui.popupMenus or org.eclipse.ui.commands Eclipse Platform has evolved so much that such extra handling cannot be necessary any more. We do not have any example code for dynamicPopupMenuExtensions in RSE, so it is hard to understand how this would have been used. Anyways, migration docs should be written explaining how to migrate from dynamicPopupMenuExtensions to org.eclipse.ui.commands (best option) or org.eclpse.ui.popupMenus See also similar bug 185552 for removing remoteSystemsViewPreferencesActions. All the client needs to do, is contribute a handler class that opens a specific preference page. This handler class can be derived from a utility class in RSE. Because the specific preference page is likely contributed as well, so the preference page's plugin needs to be activated anyways, it is very likely that having to specify a class doesn't even activate an extra plugin. Migration docs should be written explaining how a custom preference page can be contributed. As an Example, the existing RSE preference page show action should be contributed through one of the two methods mentioned above. When this is done, * class SystemCascadingPreferencesAction will most probably be obsolete (since core Eclipse cares for populating the menu already), class * class SystemShowPreferencesPageAction will need to become API since clients will need to derive from it - unless we'd be able to use the commands extension point with command parameters to modify operation of the action, then it can remain internal.
The are basically 2 set's of standard Eclipse extension points which can and should be used for dynamic contributions. - Up to Eclipse 3.2.x the extension points refering to the action framework are preferable: - org.eclipse.ui.actionSets - org.eclipse.ui.editorActions - org.eclipse.ui.popupMenus and - org.eclipse.ui.viewActions - From Eclipse 3.3, the extension points refering to the command/handler framework should be used for new contributions: - org.eclipse.ui.menus - org.eclipse.ui.handlers - org.eclipse.ui.bindings - org.eclipse.ui.commands and - org.eclipse.core.expressions.propertyTesters The more powerful and flexible system is the new command/handler framework. The direct replacements for the legacy RSE extension point "dynamicPopupMenuExtensions" will be either - org.eclipse.ui.popupMenus or - org.eclipse.ui.menus. Both extension points are providing control over the visibility of a item within the target menu. Again, 3.3 is offering the more advanced possibilities. Some examples for the more well-known extension point org.eclipse.ui.popupMenus. The key with that extension point is to know the id's of the groups and separators within the menu and which kind properties to test the corresponding IActionFilter implementation for the selected object type is supporting. A simple one: <extension point="org.eclipse.ui.popupMenus"> <viewerContribution targetID="org.eclipse.rse.ui.view.systemView" id="com.windriver.ide.target.ui.rse.AttachHostShell"> <action class="com.windriver.ide.target.ui.actions.contrib.WRAttachHostShellAction" definitionId="com.windriver.ide.target.ui.actions.contrib.WRAttachHostShellAction.command" enablesFor="1" helpContextId="com.windriver.ide.target.ui.action_attach_hostshell" icon="icons/elcl16/attach_hostshell.gif" id="com.windriver.ide.target.ui.rse.actions.WRAttachHostShellAction" label="%WRAttachHostShellAction.label" menubarPath="TargetToolsMenu" style="push" tooltip="%WRAttachHostShellAction.tooltip"> </action> <visibility> <and> <objectState name="isWRConnection" value="true"/> <objectState name="adapt" value="com.windriver.ide.target.model.ITargetObjectTypeNode"> </objectState> </and> </visibility> </viewerContribution> </extension> A more complex one: <extension point="org.eclipse.ui.popupMenus"> <viewerContribution targetID="org.eclipse.rse.ui.view.systemView" id="com.windriver.ide.target.ui.rse.RefreshContrib"> <action class="com.windriver.ide.target.ui.rse.internal.actions.WRRefreshAction" definitionId="org.eclipse.ui.file.refresh" helpContextId="com.windriver.ide.target.ui.action_refresh" icon="icons/elcl16/refresh.gif" id="refresh" label="%RefreshAction.label" menubarPath="group.build" tooltip="%RefreshAction.tooltip"> </action> <visibility> <and> <not> <objectClass name="com.windriver.ide.target.ui.rse.interfaces.IWRRegistrySubSystem"/> </not> <not> <objectState name="adapt" value="com.windriver.ide.target.model.ITargetManagerModel"> </objectState> </not> <or> <objectClass name="com.windriver.ide.target.ui.rse.interfaces.IWRHost"/> <objectClass name="com.windriver.ide.target.ui.rse.interfaces.IWRSubSystem"/> <objectState name="adapt" value="com.windriver.ide.target.api.model.IModelNode"> </objectState> </or> </and> </visibility> </viewerContribution> </extension> Translating that into an example contribution for the connect/disconnect action, it would look like: <extension point="org.eclipse.ui.popupMenus"> <viewerContribution targetID="org.eclipse.rse.ui.view.systemView" id="org.eclipse.rse.ui.actions.connect"> <action class="org.eclipse.rse.internal.ui.actions.SystemConnectAllSubSystemsAction" id="connectAllSubSystemsAction" label="Connect" menubarPath="group.connection"> </action> <visibility> <and> <objectClass name="org.eclipse.rse.core.model.IHost"/> <objectState name="connected" value="false"/> </and> </visibility> </viewerContribution> <viewerContribution targetID="org.eclipse.rse.ui.view.systemView" id="org.eclipse.rse.ui.actions.disconnect"> <action class="org.eclipse.rse.internal.ui.actions.SystemDisconnectAllSubSystemsAction" id="disconnectAllSubSystemsAction" label="Disconnect" menubarPath="group.connection"> </action> <visibility> <and> <objectClass name="org.eclipse.rse.core.model.IHost"/> <objectState name="connected" value="true"/> </and> </visibility> </viewerContribution> </extension>
Thanks a lot for all these examples, Uwe! When I'm not mistaken, all of these contribute single actions only. Do you also have an example contributing a whole submenu? And do you have an idea if it is possible to suppress any existing menu items contributed by someone else in some context? I'm not sure if these use cases are indeed in use at IBM, but I think that the dynamicPopupMenuExtensions extension point would support these.
- Submenu contribution example: <extension point="org.eclipse.ui.popupMenus"> <viewerContribution targetID="org.eclipse.rse.ui.view.systemView" id="com.windriver.ide.target.ui.rse.TargetToolMenuContrib.vxWorks"> <menu label="%TargetToolsMenu.label" path="TargetToolsSubMenu" id="TargetToolsMenu"> <separator name="TargetTools"> </separator> <separator name="TargetToolsTargetConsole"> </separator> <separator name="TargetToolsHostShell"> </separator> </menu> <visibility> <and> <objectState value="true" name="isWRConnection"/> <objectState name="adapt" value="com.windriver.ide.target.api.model.IModelNode"> </objectState> </and> </visibility> </viewerContribution> </extension> - Standard actions/contributions can bee suppressed within any of the several add*Actions(...) API methods. The menu manager reference is always passed to this methods.
Work completed, checkin comment: [185554][api] Remove dynamicPopupMenuExtensions extension point Removed interfaces, classes and methods: ---------------------------------------- ISystemDynamicPopupMenuExtensionManager SystemDynamicPopupMenuExtensionManager ISystemDynamicPopupMenuExtension RSEUIPlugin#registerDynamicPopupMenuExtensions() Updated ISV Docs; modified API docs in AbstractSystemViewAdapter#addDynamicPopupMenuActions() explaining that extenders can override this method in order to contribute dynamic popup menu extensions. Examples for how to migrate to using the standard Eclipse Platform extension point, as well as the RSE API hooks for contributing dynamic popup menu extensions are covered in the previous comments.
For adding dynamic submenus, following Wiki page should help getting started: http://wiki.eclipse.org/Menu_Contributions/Problems_View_Example
To get current context, evaluate current selection -- see Workbench.getSelectionService() get current active Part in workbench
[target cleanup] 2.0 M7 was the original target milestone for this bug
