I’ve started to work on some tooling to make e4 consumable for the average developer. The first thing I’m concentrating on is tooling for the workbench model.
The key points are:
- Run in 3.x
- Run native in e4-Workbench (without the need of a compat layer)
- Run native in e4-Running-Workbench for Live-Editing
- Extensible by Workbench-Extenders to register their editors
The current editor state looks like this:
The screen shots show a running Standalone ModelEditor implemented as an e4-application. Until EclipseCon I expect to have a first alpha version for 3.x and the e4-M4-SDK.
Because we are at it: Together with Lars, Kai I’m delivering a tutorial (e4 – Anatomy of an e4-Application) at EclipseCon on writing e4-Applications so if you are interested in e4 make sure to show up at the tutorial.
If you are interested in the code and follow my progress you can checkout the code from CVS and/or subscribe to the following bug.
Tomsondev Blog 
Hi Tom,
As I mentioned over at Lar’s blog, this looks really cool. What I’m wondering is how usable the e4 setup is now with a 3.5 app? Like, is it reasonable to try to run a complex Eclipse application under e4 right now and if so how hard is that to setup?
cheers,
Miles
With the compat layer you can run your 3.x-App without any modifications ontop of e4. The compat layer is in fact “simply” translating your View, Perspective, … contributions into our EMF-Domain-Model objects calling e4-API replacements of the 3.x API. This means an 3.x application running ontop of e4 can be introspected with the Workbench Model Tooling as well.