Community
Participate
Working Groups
Build id: I20101126-1155 1. Install everything from: http://download.eclipse.org/dsdp/tm/updates/3.3milestones 2. Restart. 3. The 'Search' menu is gone. Launching an inner with "just" JDT confirms that the menu reappears. Launching an inner with _all_ plug-ins confirms that the menu is gone.
The problem is actually coming from org.eclipse.cdt.ui somewhere. Get the two CDT bundles from /cvsroot/tools: org.eclipse.cdt/all/org.eclipse.cdt.core org.eclipse.cdt/all/org.eclipse.cdt.ui Launch your inner with just core, the 'Search' menu is there. Add the ui bundle, the 'Search' menu is now gone.
The plugin.xml snippet below will reproduce the problem. <extension point="org.eclipse.ui.actionSets"> <actionSet label="aLabel" description="aDescription" visible="false" id="org.eclipse.e4.test"> <menu label="Search" id="org.eclipse.search.menu"> </menu> </actionSet> </extension> The important point here is that the menu being defined shares the exact same id as the one that comes from org.eclipse.search and that the 'visible' attribute has been set to 'false' in this case.
I have confirmed that this problem occurs in 4.1M3.
Note that org.eclipse.jdt.junit defines a similar action set extension (with 'visible' set to 'false'). The difference is that that action set ("org.eclipse.jdt.junit.JUnitActionSet") is active.
This bug may be related to bug 330801.
*** Bug 330801 has been marked as a duplicate of this bug. ***
The 'visible' attribute is set to 'true' in the action set contribution from org.eclipse.search. So, it feels to me like all of the elements defined under that action set should be visible in all perspectives unless it has been explicitly disabled via perspective customization.
It probably has to do with menu processing from multiple sources. We need to make a menu like Search exist as long as the 3 or 4 MMenuContributions exist, and be the "OR" of the visibility of all the MMCs. PW
*** Bug 331305 has been marked as a duplicate of this bug. ***
Created attachment 185112 [details] Another plugin.xml that shows the problem We have a commercial improvement of Search (a search index, plus improved UI) which also shows the problem of missing toplevel Search menu - although I didn't find any "visible:false" clause. I'm attaching the plugin.xml for reference.
Just to mention, this bug is the primary impediment for me using 4.1 as my main development environment. I need CDT installed, but it's pretty hard to live without a Search menu. The Ctrl+H keyboard shortcut is the best workaround I've found so far, but it's not really intuitive.
I don't know exactly but I found the same when installing subversive plugins
Ping, any update on this? For me, this issue is the #1 problem why I cannot use 4.1 productively.
(In reply to comment #13) > Ping, any update on this? > > For me, this issue is the #1 problem why I cannot use 4.1 productively. I'm looking at this now, possibly ref counting menus and leaving them visible=true (MenuManager doesn't render if there are no children). PW
Created attachment 188473 [details] Work in progress v01 This is the "change the generation" part. Consuming the MMenus by a reference of some kind is next. PW
Created attachment 188989 [details] Work in progress v03 Start processing the contributions. Manage visibility as the "OR" of multiple contributions. PW
Created attachment 189631 [details] handled menus as shared elements v04 This is close, I still need to account for one extra MMenuContribution in my tests. PW
Created attachment 189741 [details] handled menus as shared elements v05 Resolved the sharing of MMenus. PW
Released for tonight's I build, I20110224-2000 PW
