Community
Participate
Working Groups
Mac OS X 10.3.7 https://sourceforge.net/tracker/?func=detail&atid=580505&aid=1162142&group_id=86683 The Menu is Shell dependant and only set to the Main Shell. It seems that on Mac, when a dialog is showing which uses a Shell for its own, the Menu is changed to cover this. According to the Apple Human Interface Guidelines, - "The menu bar reflects the principles of perceived stability and aesthetic integrity. It provides a stable location where people can look for commands." - "Is always visible and available, except in circumstances such as a slideshow" - "If /all/ of a menu’s commands are unavailable (dimmed) at the same time, dim the menu title. Users should still be able to open a dimmed menu to see its contents." http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGMenus/ chapter_7_section_4.html
It is pretty distasteful that we don't match the Mac UI guidelines in such an obvious way. Unfortunately the Mac menu bar really does behave differently than the other one-bar-per-window platforms. We should make sure that SWT provides all the capabilities that are required to build compliant applications, and ensure that the UI team uses these in a way that makes Eclipse match the guidelines. Note that this could require different coding patterns on the Mac (even though the code would run everywhere). I would class this as a Polish item. See also bug #46962 which is a related performance problem.
At one point in time we used to dim the menu bar but this had all kinds of problems so I had to throw away the code. In any case, it's not what a real Mac application would do. My thinking here is that we should provide Display.setMenuBar(). SWT programs that are written specifically for the Mac would use this API and never call Shell.setMenuBar(). On Windows, Display.setMenuBar() would do nothing and the application would fail to show any menus at all (bad). I don't have any other ideas at this time.
So, if you are offering such Api, could'nt this also include putting items into the Mac application menu, which is currently not accessable? See Bug #73816 Ben
Steve's suggestion makes sense to me. Unfortunately, we're not likely to be able to fix this for R3.1, given that it would require new API in SWT and potentially significant design changes in the UI. However, it seems like the SWT team should begin discussing this with the UI team, so that there is agreement on how the new API would be used by Eclipse, at least.
Hmmh, I don't understand why the new API on Display would help with this problem? The problem occurs whenever a non-top level Shell (that is a Shell with has a parent Shell; a Dialog) is shown. The Dialog typically doesn't have a MenuBar and since it is tied to its parent shell, it should just disable all Menus except Cut/Copy/Paste in the Edit.
Because on the Mac, the workbench would be expected to explicitely manage the menubar. (i.e. no free menu bar switching on shell activation).
Yes, I understand this for top level (sibling) shells where *clever* MenuBar switching might be necessary, but for sub shells without their own MenuBar there should be no MenuBar switching at all, because sub shells leave the MenuBar of their parent alone (but disable everything).
If that handles all of the cases in Eclipse, we should just make it so. Of course, you need to worry about disabling all of the parent's menu items that are not applicable (i.e. cut/copy/paste should *not* be disabled if the dialog has a text field), and probably a host of other special case issues.
*** This bug has been marked as a duplicate of bug 249991 ***
