E4 – A new area for RCP/RIA-Applications

I’m on the road to prepare my example for the E4 talk I’m delivering on the Eclipse-Developers-Day in Karlsruhe and I have to say that in my eyes E4 is going to open up a new world for Eclipse-RCP-Developers.

Though RCP-Applications written in 3.x might not look too bad no one can deny that the UI-Design is coming from an IDE background and compared to modern Web-UIs it looks boring (which is not a bad thing per se for business applications). The problem in 3.x is that it is very hard to impossible to change the L&F of your application.

E4 provides different multiple solutions to fix the L&F:

  1. Declarative-Styleing through CSS
  2. The possibility to define your own renderes to exchange Widget A through Widget B if CSS is not enough to theme your application

To demostrate what you can achieve when you combine the 1st and 2nd possibility I create a small screencast

where you see the famous E4-Photo-Application revamped

E4 Photo Demo

A second example application is our E4-Contacts-Demo created and maintained by Kai Tödter which shows advanced css-styles like radial gradients.

Contacts Demo

I use this application to show you another nice thing you can do with E4’s declarative styling support. You can adjust the styling of your application while it is running so that you can experiment with various font and color settings WITHOUT shutting down your application.

If all this would not be enough you can run the unmodified code (please take this literally) from the example application above in your browser using the RAP-Framework.


If you are interested in E4 and what’s going on behind the scenes of the next major Eclipse-Release I hope to see you in Karlsruhe on Tuesday July 7th.

This entry was posted in e4. Bookmark the permalink.

11 Responses to E4 – A new area for RCP/RIA-Applications

  1. philk says:

    The most interesting question for me in regards to e4 is: Will I have to add the EMF bundles to my RCP app and by that adding more bloat just for some CSS styling?

    • tomeclipsedev says:

      EMF has nothing todo with CSS but yes you will definately need to have a flavor of EMF installed because the whole workbench uses it as the underlying modeling technology. You are talking about bloat to add because of EMF but you forget that we stripped down the whole code tremendously and the Runtime-Part of EMF is smaller than you think (I’d have to look up the concrete numbers). I also said a flavor of EMF because we could probably split up EMF-Core a bit more to move out things not needed like XML-Serialization.

      But you are pointing your finger on to the right thing (though on the wrong library) because today the CSS-Engine is quite an heavy thing because parsing the CSS-Stuff needs Batik if I remember correct and this is where the bloat is happening. We need to see if we can change this and how.

      • Fred says:

        Yes, a simple RCP app quickly reach 30Mo, let’s not run to 50. But who cares if it’s all server-side now 🙂

      • tomeclipsedev says:

        I just exported the Contacts-Demo and here are the figures. The total size of the exported 16 MB (14 MB zipped) where 5.5 MB is taken by com.ibm.icu and can be replaced by com.ibm.icu.base, the css stuff all in all needs batik (243+145+90KB) + css implementation (169+13+103KB) =~ 800 KB and emf (199K+64K+213K+1MB) =~ 1,3 MB (in the current packaging structure which could be changed a bit). So in reality the application has a minimum size of 10.5 MB.

        The complete list:

        5,5M – com.ibm.icu_4.0.1.v20090415.jar
        1,8M – org.eclipse.swt.cocoa.macosx.x86_64_3.5.0.v3550b.jar
        1,1M – org.eclipse.osgi_3.5.0.v20090520.jar
        1,0M – org.eclipse.jface_3.5.0.I20090525-2000.jar
        1,0M – org.eclipse.emf.ecore_2.5.0.v200906151043.jar
        689K – org.eclipse.core.resources_3.5.0.v20090512.jar
        277K – org.eclipse.core.databinding.observable_1.2.0.I20090604-2000.jar
        252K – org.eclipse.jface.databinding_1.3.0.I20090525-2000.jar
        243K – org.apache.batik.css_1.6.0.200907030925.jar
        213K – org.eclipse.emf.ecore.xmi_2.5.0.v200906151043.jar
        211K – javax.xml_1.3.4.200907030925.jar
        199K – org.eclipse.emf.common_2.5.0.v200906151043.jar
        192K – org.eclipse.core.databinding_1.2.0.I20090604-2000.jar
        188K – org.apache.commons.beanutils_1.7.0.200907030925.jar
        169K – org.eclipse.equinox.registry_3.4.100.v20090520-1800.jar
        169K – org.eclipse.e4.ui.css.core_0.9.0.200907030925.jar
        153K – org.eclipse.core.databinding.property_1.2.0.I20090526-2000.jar
        145K – org.apache.batik.util.gui_1.6.0.200907030925.jar
        119K – org.eclipse.core.resources.compatibility_3.4.0.v20090505.jar
        113K – org.eclipse.e4.ui.model.workbench_0.9.0.200907030925.jar
        103K – org.eclipse.core.commands_3.5.0.I20090525-2000.jar
        103K – org.eclipse.e4.ui.css.swt_0.9.0.200907030925.jar
        103K – org.eclipse.equinox.preferences_3.2.300.v20090520-1800.jar
        97K – org.eclipse.equinox.common_3.5.0.v20090520-1800.jar
        90K – org.apache.batik.util_1.6.0.200907030925.jar
        88K – org.eclipse.nebula.widgets.gallery_1.0.0.200907030925.jar
        85K – org.eclipse.core.contenttype_3.4.0.v20090429-1800.jar
        84K – org.eclipse.core.expressions_3.4.100.v20090429-1800.jar
        80K – org.eclipse.core.jobs_3.4.100.v20090429-1800.jar
        80K – org.eclipse.equinox.app_1.2.0.v20090520-1800.jar
        72K – org.w3c.dom.svg_1.1.0.200907030925.jar
        71K – org.eclipse.core.databinding.beans_1.2.0.I20090525-2000.jar
        68K – org.eclipse.core.runtime_3.5.0.v20090525.jar
        64K – org.eclipse.emf.databinding_1.1.0.v200906151043.jar
        56K – org.eclipse.e4.ui.workbench.renderers.swt_0.9.0.200907030925.jar
        55K – org.eclipse.e4.core.services_0.9.0.200907030925.jar
        52K – org.eclipse.e4.demo.contacts_0.9.0.200907030925.jar
        49K – org.eclipse.e4.ui.workbench_0.9.0.200907030925.jar
        44K – org.eclipse.equinox.launcher_1.0.200.v20090520.jar
        43K – org.eclipse.core.filesystem_1.2.0.v20090507.jar
        43K – org.apache.commons.logging_1.0.4.v200904062259.jar
        24K – org.w3c.css.sac_1.3.0.200907030925.jar
        21K – org.eclipse.e4.ui.workbench.swt_0.9.0.200907030925.jar
        18K – org.eclipse.equinox.concurrent_1.0.0.v20090520-1800.jar
        16K – org.eclipse.swt_3.5.0.v3550b.jar
        13K – org.eclipse.e4.ui.css.nebula_0.9.0.200907030925.jar
        11K – org.eclipse.e4.ui.services_0.9.0.200907030925.jar
        11K – org.w3c.dom.smil_1.0.0.200907030925.jar
        11K – org.eclipse.core.filesystem.macosx_1.1.0.v20090112.jar
        3,8K – org.eclipse.e4.core.services.annotations_0.9.0.200907030925.jar
        238B 3 Jul 09:26 org.eclipse.core.runtime.compatibility.registry_3.2.200.v20090429-1800
        204B 3 Jul 09:26 org.eclipse.equinox.launcher.cocoa.macosx.x86_64_1.0.0.v20090519

    • Roland Tepp says:

      The EMF core runtime library itself is quite tiny – just about 2MB, so I would argue that adding EMF itself does not add any bloat to anything.

      Plus of course – as others have already pointed out, the CSS rendering has nothing to do with EMF and everything to do with “bloat” (depending on your definition of “bloat”)…

  2. Fred says:

    Pretty cool ! Do you think e4 apps will be RAP based ?

    • tomeclipsedev says:

      They can be based upon RAP and the work for the RAP team to provide you with a runtime should much less work than it is today because they don’t need to patch the whole underlying workbench code.

  3. philk says:

    Thanks, Tom. 10 MB sounds fair enough! I think I will give it a try. Is there any document how to transform a 3.x app to E4? Will my views all still work? Or do I first have to learn EMF?

  4. philk says:

    I wonder why com.ibm.icu is not split up into fragement bundles for each language. Its just bloat to carry all this waste around when you never ever going to use all the languages it covers.

  5. philk says:

    Do I read your list correctly that the ui.workbench bundle is missing (~4MB in 3.5)?

    • tomeclipsedev says:

      Please note that E4 is a complete rewrite of the core and so you won’t see things you know from 3.x! We provide a compat layer so that you can run your 3.x plugins but that naturally adds bloat to your system you don’t want to have.

      Without the compat layer your ViewPart/EditorParts won’t work out of the box but I hope to have time soon to show how you can structure your 3.x code in a way already today that it can run on E4 without compat layer with minimal changes. Please also note that the 3.x is going to be maintained some more years so that you are not forced to switch.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s