Community
Participate
Working Groups
On Mac OS X, the preferences menu item appears in the Eclipse menu. This is correct. However, the same menu item that does the same thing also appears in the Window menu, which is correct on other platforms but not the Mac. It should be removed from the Window menu.
Billy, just for your information: I'm the owner of the org.eclipse.ui.carbon fragment (hack) that fills the standard Mac application menu with the expected menu items and hooks them to the corresponding workbench actions. My take on this problem is that SWT needs to provide abstractions and API for these issues.
*** Bug 73728 has been marked as a duplicate of this bug. ***
*** Bug 102235 has been marked as a duplicate of this bug. ***
This seems to be going nowhere. The problem is not confined to preferences. File>Exit, Window>Preferences and Help>About all duplicate standard Carbon menus. I truly don't understand the response. Exactly what SWT abstraction do you envision that would keep Eclipse from duplicating MacOS X standard menu items? What if Eclipse adds a Services menu item in the Edit menu? The actual fix for this, albeit not restricted to a fragment, is about six lines of code.
We have no public API in SWT for accessing the Mac's application menu. The org.eclipse.ui.carbon fragment uses internal SWT API that only exists on the Mac. In order to avoid duplicate menu entries, org.eclipse.platform.ui would have to find out what standard Mac menus the ui.carbon fragment is hooking up, and remove the corresponding items from the other menus. This sounds like a hack. I envision the following solution: SWT makes the Mac's application menu API so that other Eclipse plug-ins could find out about it, and install actions like Preferences, About, and Exit in the correct place depending on platform. Bob, could you please attach your six line fix as a patch? Thanks.
I'm not in a good position to make a CVS/rdiff patch file. Below is the simple patch file I actually use. It's pretty obvious what it does and where. patch: ../org.eclipse.ui.ide/src/org/eclipse/ui/internal/ide/WorkbenchActionBuilder.java change: menu.add(openPreferencesAction); to: if (!"carbon".equals(SWT.getPlatform())) menu.add(openPreferencesAction); change: menu.add(new Separator()); menu.add(quitAction); to: if (!"carbon".equals(SWT.getPlatform())) { menu.add(new Separator()); menu.add(quitAction); } change: menu.add(aboutAction); to: if (!"carbon".equals(SWT.getPlatform())) menu.add(aboutAction);
assigning to Kim
Bob: that patch can't work. The Carbon fragment relies on the existence of the actions in the menu. When it receives the various signals from the OS, the carbon fragment attempts to crawl the menu structure and find the appropriate action to run. Without them present, you can't activate About or Preferences from the Eclipse menu. We can either alter the Carbon fragment to run the commands in another fashion or just try to hide the visibility of the items in the menu.
I have a patch that will fix this problem by making certain items invisible in the menus. They're still there so the carbon fragment can find them (with a bit of modification). I agree with Andre that new API is needed to fix this properly. I'm not sure it needs to live in SWT necessarily - it could probably live in UI. As it stands all RCP developers that target the Mac will need to do the same kind of trickery if we go with the hiding solution. Perhaps the UI should create a registry for actions that have standard positions within various platform UIs. Instead of adding them manually to certain menus in the advisor you'd simply declare that you want them present and the UI would put them in the appropriate spot (depending on platform).
Could you attach your patch, please, and suggest what certain changes are needed to the fragment? Thanks.
Created attachment 24231 [details] Patch against org.eclipse.ui.ide
Created attachment 24232 [details] Patch against org.eclipse.ui.carbon
Thanks. What about the separators, e.g., before the quitAction?
Yah, they bug me too. :) If this is the path we end up taking I'll add some polish to the patch to clean those up.
*** Bug 123900 has been marked as a duplicate of this bug. ***
Deferring
*** Bug 153313 has been marked as a duplicate of this bug. ***
A bug has languished sufficiently when it's owner forgets that it exists and not only enters a dupe but fixes the dupe in a manner similar to the patch that is already attached to the original bug. I will proceed with the quick solution I mentioned before as soon as M1 is out the door. Sigh.
Created attachment 47632 [details] Patch against the workspace root
Fix committed. I've entered bug 153761 to investigate adding API to the platform that would allow easier addition to the application menu.
Verified in I20060918-2000
