Bugzilla – Full Text Bug Listing
| Summary: | [Contributions] interactions: No easy way to override the global File/Exit action | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Eric Estievenart <eric.estievenart> |
| Component: | UI | Assignee: | Paul Webster <pwebster> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | douglas.pollock |
| Version: | 2.1.1 | ||
| Target Milestone: | 3.4 M3 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 204304 | ||
| Bug Blocks: | |||
|
Description
Eric Estievenart
Is your application a truly separate application, or is it just adding plug-ins to the Eclipse SDK application? We do not permit regular plug-ins to change the behaviour of built-in menu items. For the IDE, we feel that Exit to exit the whole environment is clear. If you only want to close one window, you can use the close button on the window. If it is a separate application, the RCP work will allow you to define whatever menu items you like. See bug 36967 and the docs at http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/rcp- proposal/rich_client_platform_facilities.html It seems a bit counterintuitive that the close button has a different behavior than File -> Exit. For a long time I wanted a way to close and restore all my windows at once but I didn't expect that File -> Exit would behave differently than clicking the close button so I never tried it. Perhaps we could add a new option like "Exit all windows" which has the current Exit behavior (and perhaps only make it visible if more than one window is open), and change the behavior of "Exit" to behave as Steve suggests. This may be more intuitive for users like Steve who don't want the "close all" behavior, and would make the option easier to find for users like me who do. Alternatively, we could add a preference for "close all windows on exit", and make both the close button and the "Exit" menu follow the same semantics. If "close all windows on exit" is enabled, we should also add a menu item for "close this window" somewhere. I'm not in favour of having the wording or behaviour for Exit dynamically change depending on whether you have one or multiple windows open, or of introducing new preferences to control its behaviour. I feel adding new modes like this would complicate the UI. We could clarify that Exit exits the application, not just the current window, That is, change the wording to "Exit <application name>" e.g. "Exit Eclipse SDK" (same app name is shown in the title bar and Help > About <app name>). The OS already provides menu items and accelerators for closing a single window (on Windows: click on the top left icon, or use Alt+F4 or Alt+Space, C) Not that I'm trying to defend the idea, but I should clarify comment 2. I was not suggesting that the wording of "Exit" change dynamically. I was suggesting that Exit only closes the current window, and that we also add an additional option that exits all windows (as with the current "Exit" option). To avoid visual clutter, we could optionally make the "Exit everything" option appear only if more than one window was open (but this is not central to the suggestion). The problem isn't that we need to expose more ways to access the "close" option... the problem that both Steve and I encountered is that we expected "Exit" to have the same behavior as "close". One of us wanted the "Exit" behavior and the other didn't, but we both did the wrong thing. For me, the ideal solution would still provide both behaviors, but would ensure that "Exit" and "Close" always did the same thing. I believe this would also be in tune with the expectations of most Eclipse users. Perhaps we need some usability data to back this up, but I don't think changing "Exit" to "Exit Eclipse" would have helped. Personally, I would still have expected "Exit Eclipse" to behave like "Close". Sorry not to have answered quickly, I was between planes and urgent
bugfixes.
Our application is a truly separate application. It indeed provides
different plugins, amongst all the user interface and the development
interface (various editors, debugger, etc.).
We don't care of changing a bit the semantics of the Eclipse actions,
provided they can be overriden, to fit our customer's needs.
RCP seems to be a great thing, except that for us:
- We may not release in 3.0 but in 2.1.x, depending on the timeframe
- Our applications require a workspace, because
- we have some metadata files to be stored on disk
- we have markers (even if they point to database objects,
and are associated to the workspace root)
- We are really using some eclipse plugins, amongs all
help, update, core, debug and I'm not sure that'll be possible
with a non-IDE
- Probably other things I forget which will prevent us from using
a non-IDE client
We already managed to get rid of multiple things we don't want our
customers to see (like views/perspectives) by stripping down the
plugin.xml of the standard plugins we re-distribute (Oh yes, it is ugly,
and may even be a licensing issue ? but for now it's not yet released...),
and I wonder in which limit we could not provide a fragment which
would update just a few classes of the standard plugins, so that
they will behave a bit better (for us !) until we have found a
proper solution.
Thanks
--Steve
BTW, we already have an (infamous) kludge whic strips down some menu elements, so I'll do that for now. Another case to consider for dynamic command handlers. This would be amazingly easy to do if the Workbench only defined its menu structure using the contributions API. Moving Dougs bugs Assigning to component owner PW Part of turning the ActionFactory EXIT action into a proper command PW Fixed by bug 204304 PW |