Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "E4/Commands"

< E4
(What it is trying to do)
Line 53: Line 53:
  
 
The 2 strategies that provide the most value are <code>org.eclipse.e4.locator.ActiveChainUpdateStrategy</code> and <code>org.eclipse.e4.locator.ActiveChainLookupStrategy</code>
 
The 2 strategies that provide the most value are <code>org.eclipse.e4.locator.ActiveChainUpdateStrategy</code> and <code>org.eclipse.e4.locator.ActiveChainLookupStrategy</code>
 +
 +
= Macro Recording & Playback =
 +
 +
* From [[Architecture Council/Minutes May 15 2008#Macro Recording and Playback]]:
 +
** Commands plus Undo Stack together are good but unsure how far they will get us -- at least also need [[Architecture Council/Minutes May 15 2008#Non-UI Scripting|Non-UI Scripting]]
 +
** Cannot force all plugins to use Commands -- EMF introduced ChangeListener
 +
** Need to make the discussion more concrete, need experts to look at how Macro Recording is done in other apps
 +
** Shoot for a '''"90%" solution where editable Scripts are recorded and users can fine-tune them by editing'''
 +
** Strongly Related to [[e4/Eclipse Application Model]] (Service / Command Bus)
 +
  
 
... more to come
 
... more to come

Revision as of 17:02, 19 May 2008

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

This is available in the incubator now as 'org.eclipse.e4.locator'. It has been added to the downloadable ui psf file: http://wiki.eclipse.org/images/7/7b/E4-demos-psf-files.zip

Background

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.

ILocator

The Locator provides 2 interfaces (bear with me, the separation of implementation and use is not in the prototype :-):

  • ILocator - allow a component to look up variables (perhaps some relevant part of the model) and services.
  • IUpdateableLocator - an interface for use by service provides and variable provides:
    • UpdateStrategy - how variables are set in the locator hierarchy. An UpdateStrategy can use the IUpdateableLocator to walk the ILocator hierarchy, requesting and setting information. The UpdateStrategy also determines how events are fired when a variable changes.
    • LookupStrategy - how a request to get a variable is answered. A LookupStrategy uses the IUpdateableLocator to walk the ILocator hierarchy and retrieve the variable value that is appropriate for where the lookup was initiated.

The locator hierarchy knows its parent, children, and has the notion of an activeChild. A locator responds to activate() events by activating itself and its parent chain (all the way to the root locator). A locator anywhere in the hierachy has the notion of an active chain, since it can always see its parent locator, and it may (or may not) have an active child. This allows a locator to be queried for a variable whether or not it is in the global "active" chain. This is important to support the notion of local context information, for both things like commands that are local to a view and for nested components.


Workbench Strategies

The 2 strategies that provide the most value are org.eclipse.e4.locator.ActiveChainUpdateStrategy and org.eclipse.e4.locator.ActiveChainLookupStrategy

Macro Recording & Playback


... more to come

Back to the top