Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
E4/Commands
Random thoughts and constraints
Handlers
Some thoughts on executing handlers in E4:
- Commands should be easy to execute
- When a command executes it should have access to the parts of the model that it cares about
- A command should always be able to determine if it can execute
- A command in a local context (like within a view) should always be presented with its local state
Menus
Thoughts on menus in E4:
- The application or product should have final say one which menus are visible or not.
- Should menus be request driven: MenuItems check their visibility and enabled state before they appear, in the desktop case on an SWT.Show event
- Should menus be event driven: property change events update the MenuItems, creating, disposing, and enabling them asynchronously
Toolbars
Thoughts on toolbars in E4:
- they share a lot of code with menus in the Eclipse framework: this can make the code for both complicated (perhaps by necessity)
- Should toolbars be request driven: ToolBars are update by a request into the framework, potentially a layout or perhaps timer driven
- Should toolbars be event driven: property change events can update the tool items and add/remove them from toolbars where necessary
Locator Prototype
The idea of commands being backed by one or more handlers provides flexibility for many of the scenarios we have in Eclipse. One aspect of the command framework that does not handle edge conditions easily is the global application context.
It works well for commands that don't care about state, or are always enabled. Actions that must simply be executed, like About and Exit. Also, commands that are contributed by specific parts work well, as they tend to be instantiated by the part and have access to source of "local contexts": the part and its member variables.
In 3.2 the org.eclipse.ui.services.IServiceLocator
was introduced, to try and break the workbench dependency on "going global" to get information and services. Most of the implementation to date has focused on allowing "more local" implementations of a service to answer questions asked by the part. This work is important to help provide the ability to nest one component within another. But it's possible that it can be extended to help with the problem of having access to the correct information that a handler needs to execute or a menu item needs to determine its visibility.