Community
Participate
Working Groups
On Mac OS X, if you close the Main Eclipse window the appication exist and the menu bar disappears. This is not consistent with Apple's Human Interface Guidelines (though it is how applications are expected to work on other platforms.) On the Mac, the application should only exit when the use selects Quit from the Eclipse menu. The menu bar should remain present when the last window is closed and allow the user to open a new window.
We could be sneaky about this and dork around with hidden windows and whatnot but this seems like a good candidate for 4.0. Though it only is readily apparent on the Mac the ability to have a windowless UI app is also applicable on other platforms. Ie: apps that dont have a window but live in the windows system tray. This would mean us reconsidering our actions/commands and see if it makes sense to have the ability for them to be keyed off the workbench instead of a particular window.
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
Prakash is now responsible for watching bug in the [Mac] component area.
Created attachment 180516 [details] Patch v01 This feature doesn't make much sense from the IDE perspective, but should be useful for the RCP apps. The patch enables the windowless application + adds the feature to the IDE. When no windows are available, the main menu stays now with just one menu item - New Window.
Boris/Paul, Need your inputs on this feature.
From a Mac perspective that is not correct behavior. The menus in the menu bar are constant regardless of which windows are or are not on the screen. Menu items in the menus are usually constant as well aside from a few special cases like Bookmarks in a web browser. Menu items are disabled when they are not functional do the state of the application but they do *not* vanish and appear according the state of the application. This assists with muscle memory and usability. Arguably other platforms should do likewise. Tog on Interface laid out the reasons why 20 years ago, and nothing had change din that respect since. But certainly on the mac users expect that their menus are stable.
(In reply to comment #6) > From a Mac perspective that is not correct behavior. The menus in the menu bar > are constant regardless of which windows are or are not on the screen. Menu > items in the menus are usually constant as well aside from a few special cases > like Bookmarks in a web browser. Menu items are disabled when they are not > functional do the state of the application but they do *not* vanish and appear > according the state of the application. This assists with muscle memory and > usability. The patch is not the final version :-) We need to rework on the other ActionFactory actions, WorkbenchSourceProvider, detached views etc to complete this feature. The patch is just to see whether this feature will work properly on Mac.
(In reply to comment #5) > Boris/Paul, > > Need your inputs on this feature. If org.eclipse.ui.application.IWorkbenchConfigurer.getExitOnLastWindowClose() was always true in the past, then ideally you should make it so that a new workspace has it set to false on cocoa, but existing workspaces have it as true. As for WorkbenchWindow menus items, they'll disappear with the last window. The infrastructure that allows them to exist is totally gone with that last window. Even if you could make them hang around safely (and I believe that's not possible) it's a lot of work and there are much higher priority items we need to invest time in. PW
Scott, do you have any opinion on this?
(In reply to comment #7) > ActionFactory actions, WorkbenchSourceProvider, detached views etc to complete Although I did have an idea for a quick hack :-) Simply clone the SWT menu hierarchy so you have a dummy set of disabled SWT MenuItems. The you could leave New Window and Exit enabled. Of course, if they picked New Window you'd have to dispose your dummy menus. PW
(In reply to comment #9) > Scott, do you have any opinion on this? Well, starting in 3.7 you can address this with Display.getAppMenuBar(). Clone the workbench window's menus, as Paul suggested, and then add them to the Display's menu bar. For compatibility Shell.setMenuBar will still override the application menu, but when there are no more shells the Display's menu bar will be used. I agree, in principle, with the gist of the bug description: Closing the last window of an application shouldn't automatically exit the application, but I think that's mainly relevant only if you have a Mac-style, document-based application, like SimpleText or Xcode, for that matter. The workspace isn't a 'document' in the Mac sense of the word. It does behave like a document, though. Maybe the right behavior when you close the workspace should be to leave the Quit and Switch Workspace items enabled. File -> New doesn't make sense, because you can't create a project or file outside of a workspace. Preferences and About make sense, too -- I can't recall how many preferences are global in scope.
Created attachment 181986 [details] Patch v02 Patch v02.
Hi! I think
(In reply to comment #12) > Created an attachment (id=181986) [details] > Patch v02 This is a *lot* of structuring and changing that I don't think is appropriate. If this is extra functionality that's supported on the Mac, can the application menu bar be filled in with the 3 or 4 items that would be appropriate in the cocoa fragment? Quit, Preferences, About, and New Window are obvious candidates. PW
(In reply to comment #14) > This is a *lot* of structuring and changing that I don't think is appropriate. As per the functionality, the changes are minimal. If there is an appMenu available, then fill that menu bar. Major changes changes are in our actions, which assumes that there is always a workbench window available. Many actions are currently performing well without a workbench window (new, import, export, restart, switch workspace, clean, build, help, etc) Even earlier, it was possible for the client to invoke these actions without a workbench window (by a popup menu in a tray item) - it just that no one did that. If we are not comfortable about changing our actions, we can probably stop at giving ability to fill the app menu and not do anything in the IDE. As I've mentioned earlier, having IDE as a windowless application doesn't make much sense, but its a very valuable one for the RCP apps and clients already expect it (like Bug#284028 C#20).
Created attachment 182191 [details] Patch v03 Just the framework for supporting the windowless apps. No change in the actions/IDE to support this.
Created attachment 182192 [details] A sample windowless RCP app Changes done for the default RCP mail app: (1) Added these lines IWorkbenchConfigurer.setExitOnLastWindowClose(false); IWorkbenchConfigurer.setSaveAndRestore(true); (2) Added application menu via the menucontribution in the plugin.xml to the application menu URI (menu:org.eclipse.ui.application.menu) (3) Made the bindings to be in the workbench context instead of default context, so that they are active when no windows are available. Now with the above changes, you can see that when no window is available, the application menu is displayed. Also, when a non workbenchwindow is active (like the message dialog), the application menu is displayed - instead of an empty menu.
Created attachment 182363 [details] Tests
Created attachment 182364 [details] zipped workspace to be in the o.e.ui.tests/data for testing
Paul/Boris, I get so many CNF exceptions when I run the test WindowlessSessionTest.testWindowlessWorkbench() But when I run the test application directly, I'm not getting any errors. Any idea of where I'm doing wrong?
For the menu that lives without any windows, the term Application menu could be misleading, as it might be ambiguous with the errrrr the "Application menu" (the one with the About, Preferences and Quit). Probably we should term this as Workbench menu and change the URI to menu:org.eclipse.ui.workbench.menu and rename methods accordingly.
(In reply to comment #20) > Paul/Boris, > > I get so many CNF exceptions when I run the test > WindowlessSessionTest.testWindowlessWorkbench() But when I run the test > application directly, I'm not getting any errors. Any idea of where I'm doing > wrong? Paul/Boris, Any luck with the testcase?
I agree that this could be interesting for certain RCP apps, but the Eclipse SDK should not behave this way. Eclipse is not a document-based application, and its primary purpose is not something that's often done in the background. Apple even has a specific guideline for this (see "Closing Windows"): http://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGWindows/XHIGWindows.html#//apple_ref/doc/uid/20000961-TPXREF56 We should keep behaving like iPhoto, Disk Utility, etc.
Created attachment 185111 [details] Patch v04
(In reply to comment #24) > Created an attachment (id=185111) [details] > Patch v04 minor comments: shouldReturnNoWindowError(*) - shouldn't that use StartupThreading, like all other calls in the initialization? I didn't see a call to IMenuService#releaseContributions(*) PW
(In reply to comment #25) > shouldReturnNoWindowError(*) - shouldn't that use StartupThreading, like all > other calls in the initialization? But why? Its called in the initThread of openWindows(). > I didn't see a call to IMenuService#releaseContributions(*) Is it ok to do that it in the shutdown() method?
Created attachment 185292 [details] Patch v05 Patch v05 (Patch v04+releaseContributions() call)
Patch v05 released to HEAD
Wow, that's quite a big amount of code for that (didn't check though whether this is needed or not). Do we really need the new context? It looks weird in the 'Keys' pref page: When: 'Workbench'. Also, it doesn't seem to work, e.g. if I assign commands using that context they won't be enabled - hence the context is very misleading. I think we should be very careful in defining a new context and avoid it if possible.
(In reply to comment #29) > Do we really need the new context? We need a context to be activated when there are no workbench windows. Couldn't use existing ones for that.
(In reply to comment #30) > (In reply to comment #29) > > Do we really need the new context? > > We need a context to be activated when there are no workbench windows. > Couldn't use existing ones for that. No other way to do that? I still think it's wrong that this appears in the UI.
(In reply to comment #31) > No other way to do that? I still think it's wrong that this appears in the UI. I didn't find any other way to do that. If it doesn't appear in the UI, then how does a user assign a key binding to a command when no workbench windows are present?
(In reply to comment #32) > (In reply to comment #31) > > No other way to do that? I still think it's wrong that this appears in the UI. > > I didn't find any other way to do that. If it doesn't appear in the UI, then > how does a user assign a key binding to a command when no workbench windows are > present? Well, I would interpret 'Workbench' context as the context enabled when a workbench is active and not the other way around and I would also expect that if I bind an existing command to it (e.g. Save) it will work when a workbench window is active.
A better name for the context might be "Application Menu" but that should only appear for Mac users. It doesn't make sense to pollute the UI for more than 90% of our users just to fix this bug.
(In reply to comment #33) > [..] and I would also expect that > if I bind an existing command to it (e.g. Save) it will work when a workbench > window is active. These are the general problems that commands don't declare their context (only key bindings can declare a context, see bug 53402) and that the context hierarchy is not shown to the user any more (bug 185517).
Verified in I20110124-1800
Looks like this fix did not make it into R4_development. Please close again if I was wrong.
Aggregate move to M5. Retarget to a different milestone if you wish...
Note that the first fix caused follow-up problems, see bug 333417.
I don't think the fix works in any of our current streams. It does not work for me on Mac 64bit with either 3.7.2 or 3.8M6. As it does not work in current 3.x streams, I don't that it is a "must have" for 4.2 at this time. Another point to consider is that, as said in comment 11 and comment 23 this feature has rather dubious value for Eclipse. As Scott said, about the only useful items we can have in the "windowless" menu would be "switch workspace". "quit", "about", and, possibly, "Help".
(In reply to comment #40) > I don't think the fix works in any of our current streams. It does not work for > me on Mac 64bit with either 3.7.2 or 3.8M6. It's correct and intended that the Eclipse SDK still exits when the last window is closed. This bug only added infrastructure for products which opt-in to this behavior by calling IWorkbenchConfigurer#setExitOnLastWindowClose(boolean) In the SDK, the only visible difference is probably that the org.eclipse.ui.contexts.workbenchMenu key binding context is not defined in 4.2. But applications that enable this behavior will have a hard time on 4.2.
Related commits: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=5591eb305125dbb7fc5bd550c5b05e687583ef5f http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=0f395be0afc845334cb7d655e643cec93bf36dd8
The Gerrit's review link with back port for master: https://git.eclipse.org/r/#/c/36652/ Daniel
(In reply to Daniel Rolka from comment #43) > The Gerrit's review link with back port for master: > https://git.eclipse.org/r/#/c/36652/ What is the purpose of the patch? What exactly does it fix? How is it related to commits mentioned in comment 42? To test the patch, I created an RCP mail template app and modified its ApplicationWorkbenchAdvisor class by calling configurer.setExitOnLastWindowClose(false) in the initialize(*) method. Then I run the app in Eclipse 3.7.2, 4.5 and 4.5 with the patch. In Eclipse 3.7.2 it works as expected - closing the app's window doesn't close the app, the app icon is still present in dock and menu. In Eclipse 4.5 (without the patch) the app crashes when closing its window (NPE Workbench.getActiveWorkbenchWindow(*)). With the patch the app doesn't start (NPE in WorkbenchMenuService.getMenuModel(*));
(In reply to Wojciech Sudol from comment #44) > In Eclipse 4.5 (without the patch) the app crashes when closing its window > (NPE Workbench.getActiveWorkbenchWindow(*)). > With the patch the app doesn't start (NPE in > WorkbenchMenuService.getMenuModel(*)); It seems the patch needs to be more adjusted to the new E4 architecture. Unfortunately its original version is not applicable for 4.5 without any changes I will try to fix it, Daniel
From reading the history of this bug -- even though I don't understand it :) -- seems clear no one is "close" or "actively" working on a fix for 4.4.2. (It had originally been targeted to 4.4 M5, and then re-opened, so I believe it "got lost") I'll move to "Mars", but if anyone knows better, feel free to set as you like. (Or, "unset" if even Mars is out of the question).
As everybody agreed, the behavior of the Eclipse SDK should not change (neither on the Mac nor in general). Adjusted the summary. This bug is now about making IWorkbenchConfigurer#setExitOnLastWindowClose(boolean) work (again). As long as nobody has an actual use case for this and nobody commits to working on a fix, it doesn't make sense to have a target milestone set. Clearing target. Maybe the trigger for this bug was actually bug 283345 / bug 375744, which finally made the "Confirm Exit" dialog work on the Mac as well.
