Bug 338879 - Make pde editor context menus extensible
Summary: Make pde editor context menus extensible
Status: RESOLVED FIXED
Alias: None
Product: PDE
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.7   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 enhancement (vote)
Target Milestone: 3.7 M7   Edit
Assignee: Curtis Windatt CLA
QA Contact:
URL:
Whiteboard:
Keywords: contributed
Depends on:
Blocks:
 
Reported: 2011-03-03 21:35 EST by Jeff McAffer CLA
Modified: 2011-03-28 07:35 EDT (History)
3 users (show)

See Also:


Attachments
extend pde editor menus (5.08 KB, patch)
2011-03-03 21:35 EST, Jeff McAffer CLA
no flags Details | Diff
screenshot with new menu entries (60.15 KB, image/png)
2011-03-03 21:35 EST, Jeff McAffer CLA
no flags Details
new patch that limits extensibility (5.78 KB, patch)
2011-03-15 17:01 EDT, Jeff McAffer CLA
no flags Details | Diff
patch with ids (5.97 KB, patch)
2011-03-16 14:31 EDT, Jeff McAffer CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff McAffer CLA 2011-03-03 21:35:20 EST
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.
Comment 1 Jeff McAffer CLA 2011-03-03 21:35:59 EST
Created attachment 190346 [details]
screenshot with new menu entries
Comment 2 Curtis Windatt CLA 2011-03-11 15:38:14 EST
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.
Comment 3 Jeff McAffer CLA 2011-03-15 14:23:00 EDT
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.
Comment 4 Jeff McAffer CLA 2011-03-15 17:01:41 EDT
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.
Comment 5 Paul Webster CLA 2011-03-16 09:24:03 EDT
(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
Comment 6 Curtis Windatt CLA 2011-03-16 10:24:10 EDT
(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?
Comment 7 Jeff McAffer CLA 2011-03-16 14:31:59 EDT
Created attachment 191331 [details]
patch with ids

As requested, this patch has ids on the context menus.
Comment 8 Curtis Windatt CLA 2011-03-17 16:17:46 EDT
Applied the latest patch to HEAD.  Works much better now :)

Thanks Jeff.