Community
Participate
Working Groups
The processing of the contributions done via the "org.eclipse.ui.menus" extension point does not end up with the same layout in 4.2 than we have in 3.8. This is extremely bad and is a blocker to support Eclipse 4.2 with the tools.cdt.tcf project. Things observed so far: - If two or more visible separators are left in the menu one directly after the others, they are not longer "collapsed" to a single separator. In 4.2, you get something like ... --------------- --------------- ... In 3.8, this is correctly detected and you end up with only one separator ... --------------- ... - Somehow, the order of the processing changed. In 4.2, you get something like ... Always Make Available Offline Add To > ... In 3.8, the (correct/expected) order is ... Add To > Always Make Available Offline ... - <dynamic ... /> contributions appears to have issues with the visibleWhen expression. Looks like as they are ignored in 4.2 for <dynamic .../> contributions. Except for the processing order, these things are really blocking for us in order to support Eclipse 4.2.
(In reply to comment #0) > > In 4.2, you get something like > > ... > Always Make Available Offline > Add To > > ... > > In 3.8, the (correct/expected) order is > > ... > Add To > > Always Make Available Offline > ... > Could you please attach enough of your menuContributions to show the menu/menu item switch? > - <dynamic ... /> contributions appears to have issues with the visibleWhen > expression. Looks like as they are ignored in 4.2 for <dynamic .../> > contributions. This is bug 383815 PW
Created attachment 218998 [details] Context menu as rendered with Eclipse 3.8
Created attachment 218999 [details] Same menu, unmodified XML, but rendered by Eclipse 4.2
For the "Add To" menu contribution, see o.e.tcf.te.ui.views/plugin.xml (http://git.eclipse.org/c/tcf/org.eclipse.tcf.git/tree/target_explorer/plugins/org.eclipse.tcf.te.ui.views/plugin.xml), line 284 - 314. ... <menuContribution locationURI="popup:org.eclipse.tcf.te.ui.views.View#Popup?after=group.categories"> <menu id="org.eclipse.tcf.te.ui.views.menu.categories.add" label="%menu.categories.addto.label"> <dynamic id="org.eclipse.tcf.te.ui.views.dynamic.categories.add.multi" class="org.eclipse.tcf.te.ui.views.handler.CategoryAddToContributionItem"> </dynamic> <visibleWhen checkEnabled="false"> <with variable="selection"> <test property="org.eclipse.tcf.te.ui.views.validAddToCategoriesCount" value="(1-"/> <iterate operator="and" ifEmpty="false"> <adapt type="org.eclipse.tcf.te.ui.views.interfaces.categories.ICategorizable"/> </iterate> </with> </visibleWhen> </menu> ... </menuContribution> ... The "Always available offline" menu item contributions is going to the same URI, but is from another plug-in. See o.e.tcf.te.tcf.ui/plugin.xml (http://git.eclipse.org/c/tcf/org.eclipse.tcf.git/tree/target_explorer/plugins/org.eclipse.tcf.te.tcf.ui/plugin.xml), line 279 - 290. ... <menuContribution locationURI="popup:org.eclipse.tcf.te.ui.views.View#Popup?after=group.categories"> <command commandId="org.eclipse.tcf.te.tcf.ui.command.offline" helpContextId="org.eclipse.tcf.te.tcf.ui.command_Offline" id="org.eclipse.tcf.te.tcf.ui.commands.offline" label="%command.offline.label" mnemonic="f" style="push" tooltip="%command.offline.tooltip"> <visibleWhen checkEnabled="true"/> </command> </menuContribution> ... I've attached two screenshots of the same menu using the same unmodified XML source once rendered by Eclipse 3.8 and once rendered by Eclipse 4.2.
On the ordering. I don't think there's a guarantee on which plugin.xml is processed first is there? You can force some ordering like we do it on the model-extension where we order stuff based upon dependencies. So is there some dependency between ui and ui.views.
o.e.tcf.te.tcf.ui requires o.e.tcf.ui.views. There might be no guarantee for the plugin.xml processing order, but the rendering of UI contributions should be consistent. Otherwise you force projects which requires to support both Eclipse 3.8 and Eclipse 4.2 at the same time to have either to maintain two code streams or duplicate the contributions in the plugin.xml with a custom <visibleWhen .../> checking for the platform version. None of those options are really effort able.
(In reply to comment #5) > On the ordering. I don't think there's a guarantee on which plugin.xml is > processed first is there? IExtensionRegistry doesn't provide for an order when returning IExtensions (it can vary from install to install). But in Platform UI we sort them by contributing plugin ID to provide some level of consistency. And in org.eclipse.ui.menus, we are supposed to apply elements within one menuContribution in document order. Those are 2 things we need to make sure we honour. I think this is more of a slip-up on our part, since I think o.e.ui.menus should end up (more or less) in the same order. PW
CQ:WINDE4BLOCKING This issue is blocking Wind River's adoption of Eclipse 4.x - we're going to stay on 3.x until this is fixed.
(In reply to comment #7) > Those are 2 things we need to make sure we honour. I think this is more of > a slip-up on our part, since I think o.e.ui.menus should end up (more or > less) in the same order. Hmm, this sounds like not overly complex, can this be scheduled for 4.3.1 ?
This bug is targeted for 4.4m5 , is it going to make the milestone ? Can it be backported into 4.3.2 ?
(In reply to Martin Oberhuber from comment #10) > This bug is targeted for 4.4m5 , is it going to make the milestone ? > Can it be backported into 4.3.2 ? This is
(In reply to Dani Megert from comment #11) > (In reply to Martin Oberhuber from comment #10) > > This bug is targeted for 4.4m5 , is it going to make the milestone ? > > Can it be backported into 4.3.2 ? The menu ordering is a sensitive area that we don't want to touch on the day we build our M5 candidate. If we find a good fix early M6, we can still consider it for backporting. Paul, can you look at this?
We are having the same issue moving our RCP app from 3.x to 4.x. We see issues with menu ordering both in the main menu and with order of contributions to the File and Help Menus where both eclipse plugins and our plugins are contributing. The main menu ordering can be demonstrated with the following demo. I can provide more documentation on the Help and File menu ordering if needed. I haven't analyzed these yet. Create a RCP application plugin using the Hello RCP template and add the following extension. <extension point="org.eclipse.ui.menus"> <menuContribution allPopups="false" locationURI="menu:org.eclipse.ui.main.menu"> <menu id="com.example.menu.order.myfirstmenu" label="First" mnemonic="F"> <command commandId="org.eclipse.ui.newWizard" style="push"> </command> </menu> <separator name="additions" visible="true"> </separator> <menu id="com.example.menu.order.mylastmenu" label="Last" mnemonic="L"> <command commandId="org.eclipse.ui.window.newWindow" id="newWindow" label="new Window" style="push"> </command> </menu> </menuContribution> </extension> Create a second plugin to contribute to the main menu with the following extension: <extension point="org.eclipse.ui.menus"> <menuContribution allPopups="false" locationURI="menu:org.eclipse.ui.main.menu?after=additions"> <menu id="com.example.menu.mainmenu.contribution.configure" label="Configure"> <command commandId="org.eclipse.ui.help.aboutAction" style="push"> </command> </menu> <menu id="com.example.menu.mainmenu.contribution.example" label="Example"> <command commandId="org.eclipse.ui.help.aboutAction" style="push"> </command> </menu> </menuContribution> </extension> The Configure and Example menus show up first. In Eclipse 3.x the Configure and Example menus are placed between First and Last. If I rename the separator to myadditions and change the corresponding locationURI, then the main menu looks like Eclipse 3.x, First Configure Example Last.
Created attachment 240419 [details] menu order plugins Here are the 2 plugins I used to test this. On 3.8 I get: First Configure Example File Last On 4.4 I get: File First Last Configure Example PW
I've also been looking at how org.eclipse.core.externaltools and org.eclipse.ui.externaltools contributes. We use these plugins in our RCP application. If I enable external tools and its required plugins with your attachments I get: On 3.8: First Run Configure Example File Last On 4.4: Run File First Last Configure Example The behavior of the Run menu contribution seems to show also that the additions separator is not being processed or processed correctly. Why did you put the File menu under its own MenuContribution? Was it a bug in 3.8 that the File menu showed up between First and Last (two menus from the next contribution)?
(In reply to Dave Dresser from comment #15) > > Was it a bug in 3.8 that the File menu showed up between First and Last (two > menus from the next contribution)? That was the way it showed up in the test plugin. I've added the File menu through the ApplicationActionBuilder now and removed it from the menuContribution: MenuManager file = new MenuManager("&File", "file"); menuBar.add(file); menuBar.add(new GroupMarker(IWorkbenchActionConstants.MB_ADDITIONS)); Now I get 3.8: File Configure Example First Last 4.4: File First Last Configure Example PW
Are you considering the 4.4 results correct? Shouldn't it be after the separator but before the next item following the separator in the menu contribution?
(In reply to Dave Dresser from comment #17) > Are you considering the 4.4 results correct? Shouldn't it be after the > separator but before the next item following the separator in the menu > contribution? I'm considering the 3.8 results "correct" for my example (although correct is a pretty loose term here, stable is probably better). I was going to look into how to process the incoming contributions in 4.4 to get them applied similar to 3.8. PW
Regarding the Run menu contributed by external tools in our full application this is associated with a perspective. On startup the Run menu shows up at the very end after Help. However, if I close the perspective and reopen it the Run menu relocates to the additions separator.
In regards to ordering the menu's like they were ordered in Eclipse 3.x, I have some preliminary results which work well for my company's RCP app. The ordering is not totally the same but it is close. I have been working with Eclipse 4.2.2 because of product requirements. I have been experimenting with org.eclipse.e4.ui.internal.workbench.ContributionsAnalyzer. The modification that seems to work well for menus is in mergeContributions method when merging children into an existing contribution. Instead of adding the menu contributions to the end of the list of children, I tried to account for the location URI in the list. See attached ContributionsAnalyzer source. I'm currently experimenting if similar logic helps with the toolbar and trimbar contributions (initially not but I haven't had a chance to step through with the debugger). Initially, I started with modifying the sort in org.eclipse.ui.internal.menus.MenuPersistence. My thinking was that starting from the top down (i.e. org.eclipse.ui.main...) it would help resolve ordering issues (see attached MenuPersistence). I'm not sure that it helps though and maybe the HashMaps in ContributionsAnalyzer.mergeContributions functionally do a similar thing.
Created attachment 241399 [details] MenuPersistence
Created attachment 241400 [details] ContributionsAnalyzer
Thanks Dave for your experimentation. I hope to look at this next week. PW
I'd still like for analysis to be done in RC1 PW
(In reply to Dave Dresser from comment #13) > We are having the same issue moving our RCP app from 3.x to 4.x. > [...snip...] > The Configure and Example menus show up first. In Eclipse 3.x the Configure > and Example menus are placed between First and Last. If I rename the > separator to myadditions and change the corresponding locationURI, then the > main menu looks like Eclipse 3.x, First Configure Example Last. I'm able to fix the problem here by taking into account "after=additions", which was missing from 4.2 but in 3.8. https://git.eclipse.org/r/26239 Uwe, What part or parts of TCF should I install to be able to reproduce your popup menus? Should I be installing the Juno version? PW
Hi Paul, the context menu screenshots had been taken from the "TCF Target Explorer" component. You can install what is available in either the Juno or Kepler release repositories. Once installed, open the view "System Management". Than you are in the place where I had been taking the original screenshots. Thanks
Here is my approach that orders menu items based on 3.x alghoritm: https://git.eclipse.org/r/26255 . I am still working on it but so far in my tests I get the same order as in 3.x.
(In reply to Uwe Stieber from comment #26) > the context menu screenshots had been taken from the "TCF Target Explorer" > component. You can install what is available in either the Juno or Kepler > release repositories. Once installed, open the view "System Management". > Than you are in the place where I had been taking the original screenshots. What elements need to be added/selected in the "System Management" view to show the "Add To" and "Always Make Available Offline" items? For testing purposes I enabled them by removing visibleWhen conditions and it seems that neither my nor Paul's patch fixes the problem. Also my patch does not work correctly with the org.eclipse.ui.externaltools contributions.
(In reply to Wojciech Sudol from comment #28) > What elements need to be added/selected in the "System Management" view to > show the "Add To" and "Always Make Available Offline" items? For testing > purposes I enabled them by removing visibleWhen conditions and it seems that > neither my nor Paul's patch fixes the problem. "Always Make Available Offline" ... To get this, you need to run a TCF agent on your host. The agent will be discovered and appear below the "Neighborhood" root node. You can build the agent from the org.eclipse.tcf.agent.git repository. "Add To" ... It will be visible if there is more than one root node (category) the selected node can be added to. If I recall it correctly, this should be the case for discovered TCF agents below the "Neighborhood" root node also.
Created attachment 242911 [details] menu order plugin with File from ActionBarAdvisor
Commotted: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=82c0f585aa66fef5b40cf6008e9f330200af3410
I think I still have more work to do here. PW
I grabbed the target explorer from luna (so I could pull in some TCF plugins from master) but now my context menu only has two items in it. Is that expected? PW
Paul, You need to create some targets and follow instructions described in the comment #29.
(In reply to Wojciech Sudol from comment #34) > Paul, > You need to create some targets and follow instructions described in the > comment #29. I had an agent running, and the context menu when the agent was selected was almost empty. Contrast with Kepler Target Explorer running in a 4.4 SDK, where the context menu with the agent selected looked more like your screen shots. PW
(In reply to Paul Webster from comment #33) > I grabbed the target explorer from luna (so I could pull in some TCF plugins > from master) but now my context menu only has two items in it. > > Is that expected? Right, things changed a bit since I have filed the bug. You see "Connect" and "Show in" if you select a node below "Neighborhood"? For luna, yes, that's correct. By using "Connect", the node is "copied" to the "Connections" category and the context menu is much richer. Down side is, with the luna stream, the "Always Make Available Offline" menu entry is gone.
With the luna stream of the Target Explorer, it looks like that the menu ordering is not different between 3.x and 4.3.x. Just checked with HEAD in both target Eclipse versions.
(In reply to Uwe Stieber from comment #37) > With the luna stream of the Target Explorer, it looks like that the menu > ordering is not different between 3.x and 4.3.x. Just checked with HEAD in > both target Eclipse versions. OK, I can still reproduce the problem (sorta) with Kepler Target Explorer in both 3.8 and 4.4. PW
OK, there were 2 areas that we didn't port from the menu contribution processing in 3.8: 1) popup any contributions were processed before other popup contributions. 2) while menu contributions were processed in order and their children inserted in order, in 3.8 each contribution's children were merged into the menu starting at the insertion point. In 4.x we were just appending each contribution's children to those already merged at the insertion point. Our pre-processing merge optimization should insert each contributions children at the beginning of the merge list, (children within one contribution still in order relative to each other). https://git.eclipse.org/r/26465 PW
Created attachment 243043 [details] 2 plugins to simulate the problem usecase: 1) include the 2 plugins and launch and SDK 2) open the Popup Order view 3) open the context menu on the root. In 3.8 the menu items are Show first, Show Second. With 4.3 or 4.4, they're Show Second, Show first. The patch fixes 4.x PW
Committed: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=9ad07e9258d2b49c461ef674e6b572cb80be9f84 Daniel will also independently review this tomorrow...
(In reply to Eric Moffatt from comment #41) > Committed: > > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=9ad07e9258d2b49c461ef674e6b572cb80be9f84 > > Daniel will also independently review this tomorrow... Looks good for me too, Daniel
OK, this now addresses some order problems in the main menus and in popup menus. PW
(In reply to Paul Webster from comment #16) > > 3.8: File Configure Example First Last > > 4.4: File First Last Configure Example This is failing again the RC2 PW
Reverting the first fix (commit 82c0f585aa66fef5b40cf6008e9f330200af3410, class MenuAdditionCacheEntry) and leaving the second commit (9ad07e9258d2b49c461ef674e6b572cb80be9f84) unchanged, brings back the correct order in both - main menu and popup menu. Tested with the plugins attached to comment 30 and comment 40. I am verifying if it is only a coincidence or if the second commit really fixes both issues.
The project's context menu is mangled (try it on a Git shared Java project): Team Compare Replace With Restore from Local History... are now no longer a group. This is a major regression which we have to fix for 4.4. In addition, Run As Debug As are still inverted with or without the fix, i.e. appear as Debug As Run As This is not a regression and only nice to have for 4.4.
Here is a patch that fixes the two recent regression bugs - main menu and project's context menu order - https://git.eclipse.org/r/#/c/27445/ . Now I am testing it to make sure it doesn't introduce any other regression.
(In reply to Wojciech Sudol from comment #47) > Here is a patch that fixes the two recent regression bugs - main menu and > project's context menu order - https://git.eclipse.org/r/#/c/27445/ . +1 Component lead. PW
(In reply to Dani Megert from comment #46) > are still inverted with or without the fix, i.e. appear as > > Debug As > Run As Our fix still doesn't address this, so I've opened Bug 436062 PW
Released as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=df3aeba23ab5b3247ac6aa47755835d17f0917f4 PW
Verified in I20140528-2000 using steps from comment 40 and comment 46.
