A week at e4 – A new milestone

Core and Compat-Layer

The work done last week was fixing the most important problems before signing of M6 this weekend, so not too many great new features have been developed but the ones already availabled got polished and improved.

The most important things are:

  • Editor-Activation time is reduced tremendously
  • Editor Sharing problems have been fixed
  • Sharing of Views like Package Explorer is available
  • A new perspective switcher has been added

An 4.0 SDK running on my OS-X looks like this:

Here are the URLs for the downloading the builds and looking at the N&N for M6

Take a look at 4.0 SDK FAQ to understand the relation between e4, 4.0 SDK and 3.x SDK.

ModelEditor

Some minor bug have been fixed but no great new feature has been added to not break existing functionality before the M6-Release.

Simple e4 IDE

This is a brand new category in my weekly status reports. I’ve started working on a small IDE like application which could be used to find missing wholes in our application and service model we need to address after the 4.0 release and help plug-in developers understand better how to prepare their code so that it runs on the e4-codebase without the need of a compat layer.

The main aspects of the Simple IDE Demo are:

  • Write some IDE like Application
  • Use git for version control
  • Experiment with Workbench-Services like a central ImageService, Internationalization-Service
  • Implement small examples people can look at and apply to their code
  • Make some of the Views workable in 3.x, 4.0 SDK and e4 runtimes


This screenshot shows the demos current state.

The code making up the above screenshot is using pure e4-APIs but naturally it doesn’t has the same functionality as the 3.x code still even those first experiments showed me that porting over stuff from e.g. JDT-UI is not as complex as I would have expected. I currently ported the Java-Syntax-Highlighting functionality and it took me about a day to get it working (though I’ve never ever worked with JFace-Text before), porting the eGit-Import Wizard was done in about 2 hours.

If you are interested in the progress, action items or even better work on one of the action items you can take a look at the wiki-page. The current export size with git-core and jdt-core bundles is around 20 MB.

A week at e4 – Share me please

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.

A week at e4 – Themeing in e4

Core Work-Items

Themeing in e4 is done using CSS like Declarative Syntax. The latest nightly builds introduce an extension point which allows people to define and contribute CSS-Files to make up a theme from different css-Files.

So now plugin-developers can contribute stylesheets which hold CSS-Definitions (classes, …) they use in their UI-Bundles. One of the interesting things in this sense is that even the latest 3.6 builds can make use of the CSS themeing support (an example is my Workbench-Modeleditor which now runs unmodified in 3.6).

The extension point is used to make up a theme in a declarative manner but IThemeManager is also registered in the OSGi-Service registry and can be access by client code e.g. to switch the UI-Theme on the fly.

In 3.x e.g. like this:

public class CSSViewPart extends ViewPart {
  private static final String CSS_CLASS_KEY = "org.eclipse.e4.ui.css.CssClassName"; //$NON-NLS-1$

  @Override
  public void createPartControl(Composite parent) {
    Bundle b = FrameworkUtil.getBundle(getClass());
    BundleContext ctx = b.getBundleContext();
    ServiceReference ref = ctx.getServiceReference(IThemeManager.class.getName());

    IThemeManager mgr = (IThemeManager) ctx.getService(ref);
    final IThemeEngine engine = mgr.getEngineForDisplay(parent.getDisplay());
    // ...
  }
}

In e4 you’d better use simply @Inject to even get the theme engine bound to the workbench instance:

public class CSSView {
  @Inject
  private IThemeManager manager;

  @Inject
  private IThemeEngine engine;
}

An example CSS-File could look like this:

.h2 {
	color: white;
    font-size: 20pt;
}

.container {
    background-color: gradient radial #575757 #101010 60%;
}

and the Java-Code to use it

final Composite p = new Composite(parent, SWT.NONE);
p.setData(CSS_CLASS_KEY, "container");
p.setBackgroundMode(SWT.INHERIT_DEFAULT);
p.setLayout(new GridLayout(2, false));

Label l = new Label(p, SWT.NONE);
l.setData(CSS_CLASS_KEY, "h2");
l.setText("This is a headline");
l.setLayoutData(new GridData(SWT.FILL, SWT.DEFAULT, false, false, 2, 1));

engine.applyStyles(p, true); // Apply the CSS-Instructions of the current active theme

The last line applies the current theme CSS-Information on all elements below the given widget.

Switching between themes is quite easy using:

engine.setTheme("org.eclipse.e4.demo.contacts.dark");

Which makes the 3.x ViewPart look like this with a radial black gradient:

or a bright one:

The currently needed plug-ins from e4 and orbit are:

Model Editor

I started refactoring some code so that model modification can be run using the e4-CommandService. Beside that I added support for Main-Menu creation and fixed some other small things.

Update: Added description how to use the IThemeEngine, …

A week at e4 – Branch, Tweak, Break and Adjust

Today I thought it would nice to do a summary about the things happing at e4 I’m part of. The headline for this week could be:

“Branch, Tweak, Break and Adjust – Lock the e4-Workbench-Model so that people won’t be broken until 4.0”

Core Work-Items

So what happened: Short before EclipseCon we started collecting proposals and feedback from people what they’d like to see changed in the EMF-Workbench-Model for the release of Eclipse 4.0 (see the PMC-Announcement). Like most stuff in Eclipse the discussion happened in the public (Bugzilla on bug 305586, the e4-dev-mailing-list, and IRC).

It was a really lively discussion at a very highlevel but I think the final result is not a compromise (which happens very often if multiple experts from different domains have to draw a conclusion) but a model which has the functionality it needs to have to address different usecases.

Defining and agreeing on the model was a team and e4-community effort but this was only half of the work the e4-committer team had to do because once we aggreed that we are all satisfied with the model we had to port over all our code. We are already quite late for this changes so putting CVS-HEAD in an unstable state was out of question.

So Eric Moffatt, Paul Webster, Remy Suen and me opened branches and adjusted the workbench code there until all our test-suites, example applications and the e4-workbench running on the compat-layer have been back in shape. This work started Thursday morning Ottawa time and was finished Friday Ottawa Lunch-Time and was as said a multi-continental teameffort coordinated on IRC. Here are the lines where we coordinated our merge commits:

[19:09:34] <paulweb515> OK tests are done
[19:10:02] <paulweb515> Hmmm, we should be ready to commit in about 10 minutes
[19:10:03] <tomschindl> merged too
[19:10:15] <paulweb515> OK, emoffatt's just got one error that he needs to deal with
[19:10:18] <tomschindl> I can check in whenever you want
[19:10:29]  about 10 minutes
[19:10:35] <tomschindl> ok
[19:10:35] <paulweb515> we're sooo close :-)
[19:11:54] <tomschindl> i'm off for dinner for 10 minutes
[19:12:56] <rcjsuen> 10 minute dinner
[19:12:57] <rcjsuen> that's as fast as me
[19:18:06] <emoffatt> paulweb515: ready (I'll do the SeparatorRenderer against HEAD after :)
[19:21:54] <tomschindl> done
[19:22:17] <tomschindl> can we commit?
[19:22:27] <yarthorn> That really was ten minutes!
[19:22:31] <tomschindl> paulweb515: does the count down :-)
[19:22:36] <paulweb515> OK
[19:22:38] <paulweb515> let's do it
[19:22:46] <paulweb515> commit away, and then ACK here
[19:23:56] <tomschindl> commit is done
[19:24:07] <emoffatt> kk
[19:24:27] <paulweb515> committed

Please note that it really took me exactly 10 Minutes to have dinner – no second more no second less🙂

Model-Tooling

Since M5 my custom workbench editor is part of the release and besides adjusting to the model changes I fixed some minor things (like NLS and stuff like this) but now that the model work is done I can once more concentrate on the editor and implement missing features. So I expect to add more features to it until next week.

Time I spent on e4

Many people at EclipseCon asked me how much time I spent on Eclipse and because I was interested by myself here are the stats I collected for the last weeks:

Description Hours Total
In the morning while going by bus to work 0.25 1.25
Every day after work 3 – 5 20
on weekend 6 – 8 7
Summary / Week 28.25 h

It’s quite an impressive number. I restarted working on e4 in March which means I spent 5 weeks (EclipseCon and short holiday in between) on e4 which is a total of 141.25 h.

How long will I invest this time? Not sure – what you see above is not really a peak in my Eclipse investment but I guess the average I spent on Eclipse stuff. I’m still trying to move some of this spare time work back to my day time job but currently it’s impossible to do so because people are not used to pay for someone doing Eclipse Opensource work for the benefit of the complete Eclipse Platform Stack (Beside naturally the compan(y/ies) who employee the Platform Team).

Things I’m going to work on next in e4 are (order by priority):

  • Model Editor improvements – Finish support for missing elements, add model documentation,
  • Model-Contributions – Fix the current contribution system and my top priority: I’d like to contribute programmatically to the model
  • DI and Tooling – One of the most important things from the tooling side but too much for me to work in my spare time
  • CSS – Start discussion on how to contribute to CSS and how to make it work in a 3.x workbench (my current hack is so dirty I can’t even tell you)