Community
Participate
Working Groups
The current search menu is created by using an ActionSet, however, this doesn't allow the org.eclipse.ui.menus extension point to make contributions to the menu. This is not allowing me to move all of the functionality I would like to the new menu extension format. A method is outlined in the following page: http://wiki.eclipse.org/Menu_Contributions/Search_Menu Showing what it would take to get a Java Search page working. I'm currently trying to move functionality from the WTP editors over to the new menu. This work can be seen in bug 212330.
It's not clear if we will find time to do this for 3.4. Help would be appreciated.
Created attachment 85569 [details] Converts Search Menu to org.eclipse.ui.menus extension point This patch converts the Search menu to use the org.eclipse.ui.menus extension point. All existing functionality is still in place, as well as the existing ActionSet that created the original menu. This patch also adds an additions seperator where plugins may contribute their own extensions to the group. This functionality was need by the WTP project to better organize some commands.
Martin, ask and you shall receive. This was a fairly simple conversion.
Thanks. I'll have to make sure first that all clients that are using the 'old' structure are still working.
I left the old information in there as well, so they should still work, only items that were added were the org.eclipse.ui.menus extensions. No hurry on my end, but would be nice to have for 3.4.
tagged as 3.4 so we don't forget it
Any updates on this?
Created attachment 97585 [details] screenshot When I try the patch and start up a fresh workspace in the Java perspective, the search menu looks like that: Java search menu entries in wrong order and no separators.
Rather not for 3.4 unless you know how to fix this.
It's not critical, but it is something that would be nice to have working in 3.5 as well.
Comment on attachment 85569 [details] Converts Search Menu to org.eclipse.ui.menus extension point See comment 8.
(In reply to comment #8) > Created an attachment (id=97585) [details] > screenshot > > When I try the patch and start up a fresh workspace in the Java perspective, > the search menu looks like that: > Java search menu entries in wrong order and no separators. > Sorry I didn't see this earlier. Fixing the above is actually pretty simple, one just needs to specify the ids for each of the contributions, and then where they should show up in the menu (i.e. after which ids). Migrating to the new menu UI extension point makes this play nicer with other plugins and RCP applications.
BTW, what order should they show up in and where should the seperators be.
See also bug 292430.
Dani, do you know why order is wrong / different after the conversion to commands? Is this an error in platform.ui or an error in text or JDT?
New Gerrit change created: https://git.eclipse.org/r/70056
(In reply to Lars Vogel from comment #15) > Dani, do you know why order is wrong / different after the conversion to > commands? Is this an error in platform.ui or an error in text or JDT? Platform UI problem. This is the main reason why (Text, JDT and PDE) don't switch. This needs to be fixed before anything can be changed.
(In reply to Dani Megert from comment #17) > (In reply to Lars Vogel from comment #15) > > Dani, do you know why order is wrong / different after the conversion to > > commands? Is this an error in platform.ui or an error in text or JDT? > > Platform UI problem. This is the main reason why (Text, JDT and PDE) don't > switch. This needs to be fixed before anything can be changed. Do you have a bug reference?
(In reply to Lars Vogel from comment #18) > (In reply to Dani Megert from comment #17) > > (In reply to Lars Vogel from comment #15) > > > Dani, do you know why order is wrong / different after the conversion to > > > commands? Is this an error in platform.ui or an error in text or JDT? > > > > Platform UI problem. This is the main reason why (Text, JDT and PDE) don't > > switch. This needs to be fixed before anything can be changed. > > Do you have a bug reference? Not sure whether there's a bug report, but bugzilla search can tell you.
(In reply to Dani Megert from comment #19) > Not sure whether there's a bug report, but bugzilla search can tell you. Hard to search in our "pool of dead bug reports > 10 000" without having a bit of context what to search for. You said the bug in platform ui is the main reason other components cannot migrate to commands. So only the different sorting and missing separators are the problem here, or are you aware of more issues behind this?
(In reply to Lars Vogel from comment #20) > (In reply to Dani Megert from comment #19) > > Not sure whether there's a bug report, but bugzilla search can tell you. > > Hard to search in our "pool of dead bug reports > 10 000" without having a > bit of context what to search for. If you can't find a related bug, then there's probably none yet. You can file a new one referring to this one here as test case. > So only the different sorting and missing separators are the problem here, > or are you aware of more issues behind this? Other problems that *could* appear: - customize perspective has issues when the action sets are no longer there. - clients contributing to group with old mechanism not handled by new mechanism - can groupMarker be replaced with separator
As this bug has been yet been fixed, I hope it's the right place to ask a question about still current workaround described in Bug 15684 [1]: If I duplicate the actionSet/menu org.eclipse.search.menu, what values to pick for @label? Whatever I supply here, overriding the internationalized label from the platform seems a pity, as my plug-in probably won't do as good a job as Babel at providing localized versions for it. [1] <https://bugs.eclipse.org/bugs/show_bug.cgi?id=15684#c6>
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
