Skip to main content
Jump to: navigation, search

Talk:Menu Contributions

Text editor popup action

How does one targetall registered context menus? One of the significant problems with the 3.2 eclipse is creeping IDE inconsistency, esp for popup menus. This inconsistency is a consequence of plugin dependent function. Having file-type dependent popups is a nice optional feature, but more critical for users is to have core function always available. There does not seem to be a mechanism to add menu items to all popups or to remove items on user preference. (I think these abilities are available for the menu bar and tool bars but I never use them, they are too slow). An example of the consequences is the AnyEdit plugin, which has pages of XML attempting to enumerate all editors in all versions of eclipse! One approach would allow regular expressions in the targetID (in the current scheme) for actions and urge editor plugin writers to adopt a uniform naming scheme. A better solution would allow users to configure global settings on popups for editors. comments moved from document (Oct 20th, 2006)

Part of this exercise will split up menu item placement from menu item visibility. You would be able to place an item in all context menus, and then specify its visibility. 21:01, 23 October 2006 (EDT)


The article references IMenuService, which seems to be an undocumented internal API. It even took me a while to realize this. 23:46, 6 November 2006 (EST)

Note: this is proposed design

Warning: This page describes design ideas, not how eclipse works. (At least I think so) 23:49, 6 November 2006 (EST)

Contributing trims from the Java code

Any chance to update these examples for the final 3.3 API?

Also, I wasn't been able to figure out how to initialize trim contribution programmatically. I've tried both plugin startup and IStartup extension point, but they both initialize after trim manager load extension points.

What I need is to do the following from the Java code (actually I only need to be able to change icon for the org.eclipse.mylyn.tasks.ui.trim command, but I wasn't been able retrieve corresponding contribution item contributed by the extension point):

 <extension point="org.eclipse.ui.menus">
   <menuContribution locationURI="menu:org.eclipse.mylyn.tasks.ui.trim">
   <menuContribution locationURI="toolbar:org.eclipse.ui.trim.command2?after">
     <toolbar id="org.eclipse.mylyn.tasks.ui.trim.container">
           label="Previous Task"

Here is what I've tried to write in Java, but strangely createContributionItems() is never being invoked:

 IMenuService menuService = (IMenuService) PlatformUI.getWorkbench().getService(IMenuService.class);
 AbstractContributionFactory contributionFactory = new AbstractContributionFactory(
 		"toolbar:org.eclipse.ui.trim.command2?after", null) {
   public void createContributionItems(final IServiceLocator serviceLocator, IContributionRoot additions) {
     IContributionItem item = new CompoundContributionItem("org.eclipse.mylyn.tasks.ui.trim.container") {
       protected IContributionItem[] getContributionItems() {
         IContributionItem[] items = new IContributionItem[2];
         items[0] = new CommandContributionItem(serviceLocator,  // service locator 
           Collections.EMPTY_MAP,  // parameter map
           null,  // disabled icon
           null,  // hover icon
           "Previous Task",
           null,  // menmonic
           null,  // tooltip
         items[1] = new TaskTrimWidget();
         return items;
     additions.addContributionItem(item, null);				
You've noticed a limitation of the system in 3.3. If a contribution manager has been filled in any contribution factories added after that point aren't added. I have a bug for that although it escapes me at the moment. There's no real way to get to the head of the queue, org.eclipse.ui.startup still runs after the first workbench window has been created (although your factory should be available if you open a second window).
I'm working to fix this but I don't have a timeframe. Another way to change a command image is to have your handler implement IElementUpdater. A call to ICommandService#refreshElements(*) will give your handler an opportunity to update the menu items. 13:33, 21 August 2007 (EDT)

Globally unique IDs?

The opening paragraphs mention that menu and command IDs "must be globally unique". Does this mean that, unlike all other Eclipse IDs, they need not be unique only class-wise? So far, in Eclipse, IDs are always qualified: a menu ID is not comparable to a command ID, simply because they never share a context (there is no instance, AFAIK, of an "object ID" in the schemas). Uniqueness of an ID has thus always meant, so far, that every other instance of the same class' must have a different ID. There is no problem in using the same ID string for a plug-in, a menu, a command, an action, a content type, etc. (Except maybe confusion in the designer's mind, but that's a different issue).

So, clarify the sentence: must menu and command IDs be unique when compared to each other and to all other IDs littering Eclipse? Or need they only be unique within the separate menu and command domains? 15:51, 22 September 2009 (UTC)

Back to the top