Community
Participate
Working Groups
Currently using the org.eclipse.ui.menu's extension point we can only contribute to a specific view. In 3.1 we should register another menu id in all the views, such that contributions can be made to that id and show up in all views.
I don't understand. Wouldn't an ObjectContribution help?
For the org.eclipse.ui.menu's extension point this is how the locationURI works: locationURI - A URI specification that defines the insertion point at which the contained additions will be added. The format for the URI is comprised of three basic parts: Scheme: One of "menu", "popup" or "toolbar. Indicates the type of the manager used to handle the contributions Id: This is either the id of an existing menu, a view id or the id of the editor 'type' Query: The query format is <placement>=<id> where: <placement> is either "before" or "after" and <id> is the id of an existing menu item
I cannot see the benefit of contributing to an unknown number of context menus in an unknown number of views. Usually, the context menu should be related to the context (that's where its name comes from). The context is either a specific view (so you'd want to contribute to the menu of that view), or a specific object that's selected (so you'd want to contribute an ObjectContribution, that works regardless of what view the object is currently displayed in). What kind of use case do you have in mind?
This is contributing 1 new context menu id that all the views share in common. So I can create say User Actions and contribute it to that context menu id and it shows up in all views, instead of copying and pasting the code to contribute it to each view individually. Remote Systems, Remote Details, Scratchpad, and Monitor should all show the same actions when right clicking on a file/folder.
So again, if your contribution is bound to the object (an IRemoteFile), then why not make a menu contribution that works on any IRemoteFile regardless of the view in which it is shown?
You are thinking popUpMenu not menu's extension point. That can't be done with the menu's extension point.
Fair enough, but why not use popUpMenu in that case? You are trying to register a menu item against an object (IRemoteFile) irrespective of where it occurs. ObjectContribution seems to be the only correct place for this, IMHO.
Certain case's can't be handled by the popUpMenu's extension as far as I'm aware. Like dynamic menu's. Thats why we used the menu's extension point for the User Actions/Compile menu's.
Created attachment 117550 [details] Patch
Attached a patch that registers the new context menu id and an example for Launch Shell of how it can be used without duplicating code for every view. Any thoughts on what the context menu id should be? I took the category id for our view's and added menu to it: org.eclipse.rse.view.menu
What about popup:org.eclipse.rse.views.common Since I't think that "popup" already conveys that we're talking about a context menu. Need to make sure though that we don't run into name clashes. I'm a bit confused though... your patch only removes a "Launch Shell" contribution to the systemView, does that mean that "Launch Shell" is currently not available from any folder in the Tableview or Monitor?
(In reply to comment #11) > What about > > popup:org.eclipse.rse.views.common You mean org.eclipse.rse.views.common without the popup as that's not part of the menu id. You specify that in the menu's extension for where you want it to go. > Since I't think that "popup" already conveys that we're talking about a context > menu. Need to make sure though that we don't run into name clashes. > > I'm a bit confused though... your patch only removes a "Launch Shell" > contribution to the systemView, does that mean that "Launch Shell" is currently > not available from any folder in the Tableview or Monitor? All of our views now register there context menu with the new id as well as there own view id. This way when we contribute Launch Shell to that menu id it is available in all views. Launch Shell shows up in Remote Systems, Scratchpad, Table, and Monitor now. You can still contribute a menu to a specific view by using the view id.
Sound good. I think you should list the affected views in the Javadoc in ISystemContextMenuConstants as well, to be clear. What about dialogs re-using the SystemView widget (form), would these also be affected?
Created attachment 117559 [details] Updated patch
(In reply to comment #13) > Sound good. I think you should list the affected views in the Javadoc in > ISystemContextMenuConstants as well, to be clear. What about dialogs re-using > the SystemView widget (form), would these also be affected? Updated the javadoc. Dialogs that reuse the SystemView widget won't have these contributions. I've also noted that in the javadoc. This is the same as it worked before when specifying a view id.
I've committed the changes.
Please add the missing @since 3.1 tag on your new field in ISystemContextMenuConstants.
Fixed.
For the records, any plugin which uses the new rse.views.common markup in order to contribute its menu to all the RSE views needs to change its bundle dependency in the MANIFEST.MF to say that it requires rse.ui version 3.1 at least: [3.1,4.0) The comment in ISystemContextMenuConstants doesn't list the remote search results view as a potential view ID where the menu is contributed, but the code checkin seemed to reference that one as well. Which is correct?
(In reply to comment #19) > The comment in ISystemContextMenuConstants doesn't list the remote search > results view as a potential view ID where the menu is contributed, but the code > checkin seemed to reference that one as well. Which is correct? > Remote Search is also a potential view ID. Javadocs have been updated.
Thanks.
Marking the bug as API since the new view ID was added.
