e4 1.0 M3 - New and Noteworthy

We welcome in the new decade with a brand new milestone of e4, the incubator for producing the next generation of the Eclipse platform. Here are some of the more noteworthy things available in milestone build M3 (January 15, 2010) which is now available for download.


Model components This milestone demonstrates the approach we plan to take towards extensibility of the e4 model. Plug-in authors can provide model components that an e4 application will merge into the application's "base" model.

Merge of components into the base model

This is done by plug-ins contributing XMI files using the Model Component container from the e4 meta-model. Model components can include parts (views and editors in 3.x terminology), commands, handlers, and most other elements from the e4 meta-model.

When an e4 application starts up, model components submitted by plug-ins are added to the base model, allowing, for example, a view to added to a perspective defined by the application.

To demonstrate this approach we created an initial base model for the e4 IDE. (It can be found in the bundle org.eclipse.e4.ide.application.) The base model contains several predefined stacks:

Default stacks

This model can be combined with model components declared in the bundle org.eclipse.e4.demo.e4photo, file xmi\components.e4xmi, to see how photo demo views are added to the base application.

Base IDE combined with the photo demo

UI extension points As we change the user interface to be based on a model, it makes sense to convert UI extension points into model components. With such an approach, a view can be described as a model component containing a PartDescriptor, rather than an extension to the org.eclipse.ui.views extension point.

This reduces the number of different paradigms that developer needs to keep in mind: all information that defines UI extension points comes from the model, and all extensions can be placed and cross-referenced in one model.

The details of this ongoing work can be found in the enhancement 296739 "Evolution of the org.eclipse.ui.* extension points"

e4 compatibility layer for Eclipse 3.x Development of the compatibility layer has returned in full swing. Simple views can now be shown in an e4 application. See the wiki page for details on how to run the compatibility layer.

An e4 application's window can be seen at the top with
    Eclipse 3.x views on its side. Below the window is the source code for the sample view that's being
    displayed on the right side of the e4 application.

e4 compatibility layer testing To ensure that the e4 compatibility layer will satisfy the contracts set forth by the 3.x Eclipse APIs, the e4 team has setup the necessary infrastructure to run Eclipse 3.x API tests against the compatibility layer. See the wiki page for details on how to test the compatibility layer. Not all tests are passing yet, but having the test infrastructure in place will allow us to quickly identify compatibility problems and track our progress.

A crop of the Eclipse JUnit view showing the results of
    a test suite that tests Eclipse 3.x APIs implemented with the e4 compatibility layer.

Persistence of application state Changes to an e4 application's state, such as where its parts are and which part is active, are now recorded individually and these user modifications are then applied to the source model. This allows changes to the source model to propagate back up to the user if a new part has been added to a stack that the user has modified.

UI model definition cleanup The structure of the e4 UI model is converging onto its final state. In this milestone we no longer provide two separate containment models (a simple one and an 'IDE' version). Since we will be able to provide all the functionality of the existing 3.x IDE using the part containment model, we've removed the IDE-style containment model altogether, cutting the model's number of classes as well as removing many sources of confusion.

The model has also been separated into a number of different levels of building blocks. These are sets of related model functionality that can be used to augment the basic capabilities of the RCP model in order to enhance the UI. This allows RCP developers to choose the specific enhancements that they really need rather than having to make an either/or choice between a model that is simplistic versus one that can support the complete existing IDE UI. The categories are:

  • Menus and Toolbars: This is a fairly generic definition, suitable for directly implemented operations.
  • RCP: This is a Sash/Stack/Part containment model very much like the legacy one.
  • Commands: This is the e4 version of the Commands/Handlers/Bindings infrastructure. Use this model if you need more sophisticated operations like key bindings, retargetable commands (Undo, copy...).
  • Trim: Using these elements allows clients to add trim containers on any side of their window and populate them with ui elements.
  • Editing: This is a specific element used to gain access to the legacy editor behaviors.
  • Shared Elements: These elements allow reuse of various model elements in different parts of the model. It will be used in the compatibility layer for supporting the sharing of views and editor areas between different perspectives.

Perspective switching We now have the ability to share UI elements across parts of the model. A placeholder in the model can be used to indicate that the referenced element should be inserted into the UI rather than rendered, meaning that the same widget structure will be used (as we share views during perspective switches). This mechanism will also be used to allow sharing more complex UI element structures such an editor area, including its sash and stack sub-structure.

Perspective Switch


TreeViewer JFace data binding has two classes, ObservableListTreeContentProvider and ObservableSetTreeContentProvider, for TreeViewer to handle the tree content corresponding to List and Set collections. These classes require a property to determine the content of subtree nodes.

XWT relies on the same concept to support TreeViewer. Two classes are provided and a property "contentPath" will be used to indicate the sub-nodes:

  <ObservableListTreeContentProvider contentPath="list"/>     


  <ObservableSetTreeContentProvider contentPath="set"/>

The screenshot below is snippet019 from the data binding framework ported to XWT.

Eclipse forms Eclipse Forms contains a set of customs widgets and other supporting classes to provide Web-like UIs by modestly extending SWT and/or manipulating style bits, colors, fonts and other properties in order to get the desired behavior. This technology was used throughout PDE multi-page editors and has been available as public API since Eclipse 3.0.

The new plug-in org.eclipse.e4.xwt.forms has been added to support creation of Eclipse forms in XWT. The support includes the latest forms API from Eclipse 3.5 and earlier.

UI profile support UI profiles are a new mechanism for meta-class management. They provide a flexible solution for managing a set of UI meta-classes, for registering new meta-classes, and for overwriting and restoring the predefined meta-classes as a whole.

Three new methods are introduced in the XWT class: createProfile(), applyProfile(), and restoreProfile().

This solution is used by XWT Eclipse forms to support overwriting the standard SWT Widgets.

Data binding change notification Data binding change notification is a tracking mechanism for all events from UI elements in a resource scope. It is particularly useful for tracking the binding data state. It is used by the e4 workbench integration to track the editor part state.

Three new API methods are added in the XWT class, and a new interface IChangeListener:

  • addObservableChangeListener(Object context, IChangeListener listener)
  • removeObservableChangeListener(Object context, IChangeListener listener)

Workbench state management In this milestone of XWT, e4 workbench integration is extended to provide automatic state management for saveable/editor parts. This state management uses data binding change notification to detect and notify the data binding state in an editor part created using XWT declarative data binding.

This solution is implemented in the class XWTSaveablePart located in the bundle org.eclipse.e4.xwt.ui.workbench. All editors should inherit from this class to leverage this support.

This state management support is used in the last version of the e4 Contacts demo to manage the change state of the Details part.

Data binding aggregation

In general, data binding establishes a binding from one property of a binding source to one property of a binding target. Multi-binding provides the ability to bind one binding target property to a list of source properties, and then apply logic to produce a value with the given input.

In the e4 Contacts demo, a full name is composed of two properties: first name and last name. A Text field is bound to a composite virtual property:

      <Binding path="firstName"/>
      <Binding path="lastName"/> 


This milestone includes initial integration with Trident, an animation engine for Java. This integration consists of the following elementary classes:

  • ColorAnimation
  • IntAnimation
  • PointAnimation
  • RectangleAnimation

These classes are driven by the class Storyboard via Event Trigger. Here is an example for the fade transition:

<Shell xmlns="http://www.eclipse.org/xwt/presentation"
<GridLayout numColumns="1"/>
<Label name="labelTarget" text="Int the animation"/>
<Button name="startButton" text="Start Animation">
<EventTrigger routedEvent="SelectionEvent">
<BeginStoryboard name="MyBeginStoryboard">
duration="0:0:3" from="0" to="255" />
</Button> </Shell>

The fade animation starts when we click on the button "Start animation", it lasts for three seconds and the alpha value will change from 0 to 255.

Data binding validation and error handling Validation is the last step in data binding operations during an update. In general, the result needs to be displayed in the UI to notify end users. There are several way to perform this notification: decoration, status bars, tool tips, message dialogs, etc. A generic solution is implemented in this milestone to support all the most useful error handling mechanisms of data binding. This solution itself relies on data binding.

Here is an example of a status bar that manages two Text fields.

XWT designer XWT Designer is a visual editor-like WYSIWYG tool. It is designed to allow applications to be designed by non-software engineers.

Here is the summary of the main features supported by XWT Designer:

  1. A tool palette view
  2. WYSIWYG authoring
  3. Support for SWT and JFace
  4. Support for XML editing with code completion
  5. Integration with the tabbed Properties view
  6. Hierarchical outline view with DnD operation, copy/paste and undo/redo
  7. Support for all layouts: including SashForm
  8. String externalization
  9. Surround With
  10. Widget style change via context menus
  11. Advanced control binding editing

This tool is tested on Windows, Linux and Mac OS Carbon/Cocoa.

e4 Workbench Designer

New visual design tool e4 Workbench Designer is a visual editor-like WYSIWYG tool for e4 workbench authoring. The designer allows you to assemble and layout an e4 application visually without needing programming or EMF knowledge. It reuses many components from XWT Designer.

The following components/features are implemented:

  1. A tool palette view
  2. WYSIWYG authoring
  3. Part layout reorganization using DnD
  4. Integration with the standard Properties view
  5. Hierarchical outline view

This tool is tested on Windows, Linux and Mac OS Carbon/Cocoa.

The above features are just the ones that are new since the previous milestone build. Summaries for earlier 1.0 milestone builds: