Community
Participate
Working Groups
Created attachment 190345 [details] extend pde editor menus The current context menus in the plugin and feature editors are not registered with the workbench so cannot be extended by menu contributions. The attached patch makes it *possible* for each editor section to register its context menu(s) and adds code to have the RequiresSection of the plugin and features editors register their menus. Topics: - Doing this allows a few extra entries to show up on the plugins in these editors. A screen shot is attached that shows 4 additional colateral entries. Note that the "Get Source Bundles" entry is mine that was the motivation for this enhancement. I'm not sure where/who is contributing the other 4 and if they should be tweaked to be less promiscuous. Certainly compare seems odd... - The current menu registrations are anonymous. I'm not sure what hte convention is in menu id-land so am not sure if there should be an id or what it would be.
Created attachment 190346 [details] screenshot with new menu entries
When populating the menu, the manager believes that it is opening on a resource selection. Specifically the manifest file that the editor is open on. Run, Debug, Compare, etc. do not need to be tweaked as they should open on all resource selections. I don't know how the workbench is getting this information though. Only the viewer is being passed during registration, not the editor. In any case, we need this to be tracked down before the change can be committed. It is even worse if you have other plug-ins installed. I have a WikiText submenu and a Fix Copyrights option. The javadoc of registegerContextMenu suggests that context menus should have unique ids. If there is only one menu for the workbench part, then the part id can be the menu id, otherwise a more unique name must be chosen and specified in javadoc. We can ask Paul or Remy for more explanation if necessary.
Paul/Remy, You have any thoughts here. With the patch the PDE manifest editor is registering a context menu for one of the viewers in the forms editor. It seems however that the selection being used is the manifest file itself (a resource) so we are getting too many contributions on the menu.
Created attachment 191251 [details] new patch that limits extensibility Ok, I found the problem. When registering the context menu for an editor you can say whether or not the editor input is considered as part of the selection used to populate/extend the menu. The default for this is true. Changing to false gets the menu being extensible for only the types that are actually selected. I also updated the patch to add the ADDITIONS marker at the end of the context menus as per the API directions in registerContextMenu. As for the of the menu, the javadoc for registerContextMenu says that if there is only one context menu in the editor then you should not give it an id. The default (part id) will be used. So I have left that. If we look to make more menus extensible then we'll have to look at the ids more closely. New patch attached.
(In reply to comment #4) > As for the of the menu, the javadoc for registerContextMenu says that if there > is only one context menu in the editor then you should not give it an id. The > default (part id) will be used. So I have left that. If we look to make more > menus extensible then we'll have to look at the ids more closely. You got it. You don't want to consider the editor input. That will restrict you to considering the ISelectionProvider (viewer). As for IDs, each context menu you are creating should have a unique ID. That allows org.eclipse.ui.popupMenus/viewerContribution and org.eclipse.ui.menus[popup:id] to target that menu. The default (just use the part ID) works for editors/views that have one obvious main context menu (right click within the text editor, for example). That's also the most likely one to use the IEditorInput as well (if it makes sense). PW
(In reply to comment #5) > As for IDs, each context menu you are creating should have a unique ID. That > allows org.eclipse.ui.popupMenus/viewerContribution and > org.eclipse.ui.menus[popup:id] to target that menu. Jeff, can you make a third patch with unique ids?
Created attachment 191331 [details] patch with ids As requested, this patch has ids on the context menus.
Applied the latest patch to HEAD. Works much better now :) Thanks Jeff.