Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-incubator-e4-dev] Fw: Declarative UI roundup? 
Tom and others,
Just a bit of background: My research field is model-based UI design and the last years I've been building a UI modeling tool (see http://www.idi.ntnu.no/~hal/research/). The editor is based on EMF+GMF, while the runtime is built on a Apache SCXML (a statechart engine) for activation of UI parts, EMF databinding for dataflow, XSWT for describing the concrete UI, EMF for modeling the domain and Javascript (Mozilla Rhino) for scripting (both behavior of the model and scripting of XSWT). The UI model tries to abstract away the underlying technology by focusing on what information a widget supports (input/output), rather than the widget API. This makes the model toolkit-independent, but the runtime of course needs toolkit-dependent code to control the life-cycle of the real widgets.
To make the runtime a bit more flexible, it does not build the widget structure directly, but generates an XML file (in my case XSWT) that is then rendered by a library. The idea is that it should be fairly easy to use any XML-based UI description language.
The main problem with going through XML and a renderer, is that it only handles the creation process. I still need (in my case) SWT-specific code for attaching listeners and activating/deactivating widgets. 


b) Ed is right I think we need a more strongly typed / constrainted
   description language.
Strongly typing is desirable. But just as important is a uniform way of manipulating the widget structure. By using DOM or EMF, we can manipulate and listen to standardized objects. The mapping to the toolkit API is handled by a toolkit-specific library, containing all necessary toolkit-specific logic. I believe this is Angelo's approach, although he uses DOM rather than EMF. 


As I have understood TK-UI so far it uses XUL to described the UI so
Angelo has a constrainted description language it only misses an
Ecore-Description [1,2].

What I often thought about is that we could have a layered approach here:

XAML    XUL     MXML    MySpecialML
|        |        |          |
------------------------------
             |
             | Transform (XSLT, ....)
             |
           SwtXL => EMF-Modeled SWT-API
             |
       SWT-Application

This is the concept I currently have in mind for my UFaceKit-Project the
only thing I replace there is SWT through UFaceKit and SwtXL through
UFaceKitXL.
I don't like the idea of having an SWT-specific model, so UFaceKitXL (EMF model of UFace widgets) is preferable. I guess it is more difficult to make a toolkit-independent model for UFaceKit than one for SWT? E.g. how do you handle things like content providers and cell renderers/editors?
As mentioned, the model is one thing, how it reacts to changes is another. Is UFaceKitXL designed to handle changes to the Ecore objects, like adding/removing widgets, changing attributes etc? I have implemented good support for Ecore in Mozilla's Javascript, so being able to manipulate the UI through Ecore has great potential. 


I've already tested this approach in a project I had named EXSWT the
only thing missig there was the Ecore-Model for EXSWT [3].
Which was based on XSWT, wasn't it? I've worked a lot on and with XSWT and its main problem is that (although the language is/looks declarative) it is not designed to handle a live model, i.e. react to changes to the DOM. 

Hallvard

Back to the top