So the title already says what this Blog-Post is about. It will talk about the possibility to use the Eclipse 4.1 Application Platform without using SWT to develop your UI-Components.

Already the initial designs of Eclipse 4.x splitted the codebase not only into Core and UI-Components but futher broke up the UI-Components in stuff into a toolkit independent and toolkit dependent part. The concept we are using here is often referred in our talks as the “RenderingEngine” which is responsible of turning our Application Model into an UI.

In the 4.0 we violated our own design by dragging in unwanted SWT-Dependency through referenced bundles but we got rid (or better said will get because of bug 338559) of them in 4.1 and so the Eclipse 4 Application Platform we’ll be able to be used without using SWT but use the UI-Toolkit of your choice (e.g. Swing, Qt, …).

To make it possible to write e.g. Swing-Applications using the Eclipse 4 Application the only requirement is that someone wrote a replacement for the default rendering engine provided by default by the e4-Team. To find out how much effort it would be to write such a thing I’ve experimented a bit yesterday and have to admit it’s doable using the SWT-Implementation and translating into Swing calls. Hacking for about 5 hours I had a minimal Swing-Application running on.

Here’s a screenshot of my model editor which is used to connect the pieces so that we get a running application:

So what does this first experiment tell us? The Eclipse 4 Application Platform is a flexible UI Framework to build component based UI application no matter if you use SWT or not and the effort to provide a rendering engine for another UI-Toolkit is not a task of man years.

The educated reader might ask why one would want to write applications without using SWT given that Eclipse 4.1 allows you to style widgets using CSS.

There are multiple:

• SWT and Styling pixelperfect: For many types of applications I have no problems with the limitation SWT has when it comes to styling the native widgets (when e.g. writing Database-Forms) but when it want to write a stylish UI which looks as slick as applications created with other RIA technologies. Don’t believe me? Ever tried to change the background-color of a Button?
• JavaFX on the horizon: The first test reports from JavaFX 2.0 are promising and my bet is that integration into a Swing-Application is going to be easier than in SWT. I think using JavaFX will be quite nice if you’d like to include multimedia content and use animations which is something SWT has not made any progress since the early days of the Eclipse 4.0 effort
• Legacy-Swing codebase: If you have a lot of Swing knowledge and probably even source code it might be easier to stay with Swing
• Learn only one RCP-Framework: If you have to write application using different Toolkits (SWT,Swing, …) it is easier to learn only one framework currently you’ll have to keep the knowledge about Nebeans and Eclipse RCP
• You simple like Swing/Qt and want to make use of the new DI-Programming model, OSGi-Services and the new idea of the central application model

Finally what did i use to make the small application in the screen shot:

• Java 1.6 SE (swing is part of it 🙂
• Eclipse Databinding: Only the core part and Pojo-stuff
• org.eclipse.ufacekit.ui.viewers: Base implementation for JFace-Viewer like components but defined in a widget toolkit independet fashion (plus support for Generics)
• org.eclipse.ufacekit.ui.swing.jface: JFace-Viewer like components for Swing-Controls
• org.eclipse.ufacekit.ui.swing.databinding: Observable implementation of the Eclipse Databinding API for Swing controls
• org.eclipse.ufacekit.ui.viewers.databinding: Observable implementation working on top of the generic JFace-Viewer API provided by org.eclipse.ufacekit.ui.viewers