Is E4 overfocusing on Declarative UI and Scripting?

Contrary to thoughts of many Eclipsers (based on Eclipse Monkey experience) ability to develop Eclipse-based products completely in sciprting languages exists since 3.1 - for few years, since IExecutableExtensionFactory was introduced.

Technique is simple like this:

JavaScriptExtension (implements IExecutableExtensionFactory) retrieves script from location specified in extension data, execute script and returns script result (of course it shall be of type required by corresponding extension point). Technically you can implement any Java interface and derive from Java class using any JVM scripting language, so since Eclipse 3.1 there are no obstacles to develop plugins without any line of Java code ("biggest" problem is classloading issues :).

In 2005 we started a project named RCPML, which is about to develop Eclipse-based application completely in scripting languages. Besides scripting part project introduced declaraive UIs, CSS support, etc.

From end-user perspective UI definition in XML-based declarative language looks like:

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin>
   <extension
         point="org.eclipse.ui.views">
      <category
            id="category.helloworld"
            name="Scripting Demo"/>
      <view
        category="category.helloworld"
        class="org.rcpml...RCPMLExtension:/views/helloworld.xml"
        id="view.helloworld"
        name="HelloWorld View"/>
   </extension>
</plugin>

And View code itself:

<?xml version="1.0"?>
<ui:view xmlns="http://rcpml.org/swt"
         xmlns:ui="http://rcpml.org/ui">
  <label>Hello World</label>
</ui:view>

 ...where xmlns="http://rcpml.org/swt" is a package (in terms of EMF) with components reflecting SWT world, xmlns:ui="http://rcpml.org/ui" package reflect Workbench classes, etc.

We instantiate DOM from the file specified. Package-aware "renderers" maps DOM objects to corresponding problem-domain objects (SWT, etc), install appropriate listeners and translate SWT UI events to DOM events, listening for DOM changes and update views (in terms of MVC), as well as scripts (JavaScript) are triggered by DOM events and executed against DOM instances.

Besides this we support both CSS for layouting and components styling: please look at "classical" Eclipse forms tutorial "ported" to RCPML:

CSS for layouting example:

<ui:view xmlns="http://rcpml.org/forms" xmlns:ui="http://rcpml.org/ui" xmlns:core="http://rcpml.org/core">

  <core:style type="text/css">
    form#myform {rcpml-layout:grid;rcpml-layout-columns:2;}
    form#myform > hyperlink {rcpml-colspan:2}
    form#myform > text {rcpml-fill:horizontal;rcpml-grab:horizontal;}
    form#myform > checkbox { rcpml-colspan:2; }
  </core:style>

  <form id="myform" title="This is RCPML Form">
    <hyperlink>Click here</hyperlink>
    <label onclick="javascript: this.color=#ff0000">Text field label:</label>
    <text/>
    <checkbox title="An example of a checkbox in a form"/>
  </form>
</ui:view>

This RCPML stuff exists for years. Initially done as a proof-of-concept, it was used in several products including commerical ones having thousands of users. For example Zend Studio for Eclipse uses RCPML-based properties view and dialogs. If it's interesting for you see RCPML-based UI in action at second part of this screencast... so I'm a little bit aware of the problems and ideas related to modeled UI and scripting.

Is this important for E4? 

Definitely both declarative UI and scripting could be a huge benefit for Eclipse, and according to my current expertise I'd vote for EMF to be used for UI modeling instead of DOM... however many things shall be worked out. W3C have everything necessarily for years: DOM event model, JavaScript bindings, CSS formalized, etc...

I appreciate this discussion and direction very much, but having that RCPML stuff done (and as I mentioned, ability to script your plugins without a line of Java code already exists), I do not think that this is a good direction for E4: there is no conceptual changes, and both declarative UI/scripting can be introduced in Eclipse 3.5 (including fully scriptable workbench with mininal API changes).

If E4 is going to be true next-generation, we need a

Conceptual shift for UI paradigm...

As for me, this shift must be from underlying OS widgets-based approach (SWT-style) to UI decomposition down to 2D (3D) primitives and rendering to canvas (as we see in WPF). Conceptually JavaFX and WPF are about high-performance UI models transformations and rendering. JavaFX Script is a cool language for dynamic UI model manipulations. JavaFX render to DirectX/OpenGL. WPF render to DirectX. Past time Sun improving Java Runtime to support JavaFX well, Microsoft adding new features to DirectX like glyphs caching to support WPF. JavaFX and WPF UI models decompose down to rendering primitives such as lines, brushes, and fills. Everything they need is a canvas, and their performance is just impressive. (Intersing that rendering to canvas will break all the borders between SWT and GEF). Modern UI layer must be able to render UI models to canvas, and SWT looks redundant with its dependency on underlying platform components.

I'm very happy to see modelled UI discussion at E4 list, and I'm agree with most points there. But did anyone ask a simple question: "how E4 will render button, or text-edit control"? And corresponding question: "what is a physical button from E4 standpoint"... It seems like everyone silently assume that SWT will handle this... From my side, if E4 will physically treat button as underlying OS widget (e.g. GTK) - I'd prefer to consider JavaFX for my non-tooling projects (and who knows how many people will switch to Netbeans later)...

I hope discussion on new concepts will be raised soon...