Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Platform UI Command Design"
(→Command Architecture Overview) |
m |
||
| Line 1: | Line 1: | ||
| − | Starting point for menu and toolbar placement of commands. | + | Starting point for menu and toolbar placement of commands. Please contribute comments and suggestions in Talk:Platform_UI_Command_Design |
= Original RFC = | = Original RFC = | ||
Revision as of 08:28, 17 August 2006
Starting point for menu and toolbar placement of commands. Please contribute comments and suggestions in Talk:Platform_UI_Command_Design
Contents
Original RFC
Requirements
- Provide a single concept for contributing to the workbench. Right now, there are two distinct ontologies: actions and contribution items; and commands and handlers.
- Support the addition and removal of plug-ins.
- Separate model and behaviour from visual presentation. Adhere more closely to the Model-View-Controller pattern. Model and user interface separation.
- Extensibility. Every group of items in the user interface (e.g., menu, tool bar, etc.) should be extensible – both in structure and content.
- Universal keyboard shortcuts. A user should be able to add a keyboard shortcut to any item that appears in the user interface (e.g., menu item, tool item, menu, etc.).
- Separation of structure and content. The structure of the menus (e.g., groups) should be defined independently from the items.
- No implicit declarations of structure or content. Everything should be explicit.
- Fine-grained control over visibility.
- More intelligent updating of elements within the user interface. Support for lazy updating for elements that are not showing within the user interface. This lazy updating should be handled automatically – without the elements needing to understand whether they are showing.
- Improved control over menu definition and item ordering. This will affect the “Search” and “Run” menus.
- The selection should be capable of overriding the behaviour of a user action. For example, if a Java element is selected in the Resource Navigator, a rename should be a refactoring rename.
- Address the difficulty in determining the keyboard shortcuts to show for context menu items.
- Support dynamic entries in top-level menus. For example, the recently opened files in the “File” menu should be possible using only public API.
- There should be an easy way to define the default behaviour in response to a user action (i.e., default handler for a command).
- Provide localized control of the model, view and controller elements talked about in this proposal. This includes such concepts as automatic addition/removal as parts are become active/inactive, and automatic removal as parts are destroyed.
- Allow the same user interface element to be placed in multiple locations. Reduce duplication in the syntax, and try to reduce memory usage.
- Provide facilities for finding and triggering elements within the user interface. This is intended to provide better support for the welcome facilities, cheat sheets, macros and scripting.
- JFace must not lose functionality. Everything that can be accomplished with JFace must still be possible in JFace, even if the API changes radically. Similarly, everything that can be accomplished with the workbench must still be possible in the workbench.
- Contribute all of the workbench and IDE model, view and controller elements using the API from this proposal. Everything that the workbench and IDE can do should be possible for third-party plug-ins as well.
- Contributing arbitrary controls (e.g., combo boxes) to Eclipse, where appropriate.
Command Architecture Overview
Commands and Handlers
Commands are managed by the org.eclipse.ui.commands extension point and the ICommandService.
Handlers are managed by the org.eclipse.ui.handlers extension point and the IHandlerService.
KeyBindings and Contexts
KeyBindings are managed by the org.eclipse.ui.bindings extension point and the IBindingService.
Contexts are managed by the org.eclipse.ui.contexts extension point and the IContextService.
Menus
Currently, menus are managed by 4 extension points:
- org.eclipse.ui.actionSets
- org.eclipse.ui.editorActions
- org.eclipse.ui.viewActions
- org.eclipse.ui.popupMenus
Programmatic contributions are managed through a number of locations: IActionBars, IViewSite, IEditorSite ... more to follow
Historical Information
The Contribution proposal started a couple of releases ago Contribution RFC
There are discussions in a number of places: