In fact it’s been 2 weeks since my last blog entry about the progress that’s been made in e4. So what has happened in this 2 weeks:

Conferences

Kai Tödter and Boris Bokowski presented e4 at Jax2010 in Mainz. It is of real importance to tell the community about e4, which expectations they should have and more important which one they should NOT. The release we’ll ship this summer is an Early Adopter Release which though stable can’t be compared to the stability and feature richness of Eclipse Helios (and the 3.6 Release of the platform).

Core and Compat-Layer

A new annotation @Preference

One of the first nice things that’s been added is the support for Perference-Injection using a new @Preference-Annotation. So if you need access to a preference in your Part-Class you can now write:

import org.eclipse.e4.core.di.extensions.Preference;

public MyEditor {
  @Inject
  @Preference(value="textcolor")
  private String textcolor;
  
  @Inject
  public MyEditor(Composite composite) {
    
  }
}

Here’s a list of the most important annotation you might want to use:

• @javax.inject.Inject: Mark a field/constructor/method to be recognized by the DI-Framework
• @javax.inject.Named: Define the key under which the value to be injected in the DI-Context (by default the fully qualified class name is used)
• @org.eclipse.e4.core.di.annotations.Optional: Mark an inject value to be optional so if it can’t be found no error is thrown
• @org.eclipse.e4.core.di.annotations.Execute: Mark a method to be executed by the Command-Framework
• @org.eclipse.e4.core.di.annotations.CanExecute: Mark a method to be visited by the Command-Framework to check if a command is enabled
• @org.eclipse.e4.core.di.extensions.Preference: Mark a field/method-parameter to be filled with a value from the preference store
• @org.eclipse.e4.workbench.ui.Persist: Mark a method in your Part-POJO to be called when the workbench issues a save-request

Shared Parts

One of the quite interesting things of Eclipse is the concept Perspectives and shared Parts between them. This is quite interesting from the point of the rendering framework because you suddenly don’t have a simple UI-Tree but one with Shared-Subtrees. I don’t go into details how this is solved but only let you know that this feature is now available in the latest builds.

Here are 2 screenshots of a running Eclipse 4.0 Early Adopter Release:
Java Perspective

CVS Perspective

I’ve been using the Eclipse 4.0 Early Adopters stream in the last few days a bit to work on e4-Samples and although it works, it’s sometimes a rough ride and I’d say productivity is 70% of the one I have with the 3.x stream but I’m still confident that at the time we ship it most of the problems are fixed (e.g. unconstrainted c&p in Dialogs).

Drag & Drop

Initial support for Drag and Drop has been added but it’s still a bit rough to use and often completely destroys your Workbench-Layout.

Model Tooling

New Features

Beside fixing bugs I added the following new features:

Support for Icon-URI creation

Initial Support for extended Application-Models

IMHO one of the coolest features of the Eclipse Platform 4.0 is that if the Application Model coming with it by default doesn’t suite your needs you are free to extend it and add support for features you need to have in your specific application.

An extended Application-Model can look like this:

To extend the e4-Application Model you use standard EMF-Tooling (in the screenshot we extend the main Application-Entity and add new feature). To make the Model-Editor aware of such new Entities and Features I introduced an extension point which allows external parties to extend the Base-Editor.

Take a look at the 2 editors where the upper one views an extended Application-Model whereas the lower one displays a default one.

Single-Sourceing

With single sourceing I mean that one writes a NATIVE e4-Component and runs it unmodified in:

Native e4.0-Application

Eclipse 4.0 SDK (=3.x codebase with compat-layer)

Eclipse 3.x SDK

I’ll describe in more detail in another blog post hopefully soon how I managed to make an e4-Component live other environments but for the ones who can’t wait.

The trick here is that the I’ve written an EditorPart-Implementation which makes the e4-Component believe it is running in an e4-Application (I simply set up such a virtual e4-Application-Context-Tree inside 3.x or inherit the compat-layer ones in 4.0).

This makes my Eclipse SDK 3.x / 4.0 integration look like this:

import org.eclipse.e4.tools.emf.editor3x.compat.E4CompatEditorPart;

public class E4WorkbenchModelEditor extends E4CompatEditorPart {
  public E4WorkbenchModelEditor() {
    super("platform:/plugin/org.eclipse.e4.tools.emf.ui/org.eclipse.e4.tools.emf.ui.internal.wbm.ApplicationModelEditor");
  }
}

So the Component URI which is in an e4-Application part of the application model is passed to a generic E4CompatEditorPart which holds all the magic and because the CSS-Themeing is applied to 3.x, 4.0 and native e4-applications (see here how and why this possible) my editor looks and behaves the same on all 3 platforms.