Re: [eclipse-incubator-e4-dev] CSS and declarative UI

["David Orme" <djo@xxxxxxxxxxxxxxxxxxxxxxxxx>]

Welcome, Hallvard!

To others: Hallvard rocks. :-)  He and I have been working together on XSWT (on and off) for over a year.

Generally: All good points.  I'm particularly interested in seeing if we can find a good solution to making an EMF-based XSWT implementation into an open system, as you point out, so that we don't lose one key benefit of XSWT: that it works with all current and future SWT controls with zero extra effort.


Regards,

Dave

On Mon, Jun 30, 2008 at 6:55 AM, Hallvard Trætteberg <hal@xxxxxxxxxxx> wrote:

Hi all,

I've just become member of this list, so let me first introduce myself before making some comments to the "CSS and declarative UI round up" thread".

I'm a researcher working in the field of model-based user interface design. In my thesis I developed a UI dialog modeling language called diamodl (see http://www.idi.ntnu.no/~hal/research/diamodl/) and over the last years I've been working on Eclipse-based tools for it, both editor (GMF) and runtime (EMF, Databinding, XSWT/SWT and _javascript_). Diamodl essentially models flow of data in a data binding graph and activation of dialog elements based on a State charts. Thus, the model can be thought of as glue between the application data and the toolkit, i.e. an abstract/logical UI model as opposed to a model of the actual widgets.

So, what is the relevance for e4? I see several:
- I've been committing code to XSWT the last years, to make it more usable for my diamodl runtime, like XSWT stylesheets, _javascript_, more flexible XML. (Unfortunately, there is no release with these features, but the code is in CVS.). Based on this work, I have some thoughts about how it may be improved to include other hierarchical and related data, like view structures and data binding graphs.
- Scripting support has been mentioned as important for e4, and Rhino has been integrated with both EMF and XSWT as part of my work.
- Since the diamodl runtime is based on so many relevant technologies, diamodl's concepts (variables for data, computations for data transformations and connections for data bindings) may also be relevant for a model-based e4.

Some more specific thoughts on the issues in this discussion:

Using EMF for modeling the GUI, what does that entail?
- One of the advantages of XSWT is that it does not rely on a closed model, since it uses reflection for looking up classes, constructors, methods and properties. If we go for an EMF model, we must make sure it is easy to extend it at runtime, e.g. by loading an EMF fragment for a new widget or generating a model fragment based on reflection (possibly pregenerated).
- It's not really clear what the role of EMF will be. One possibility is to use it as the runtime representation of the UI, so that a serialization and subsequent deserialization of it is enough to restore the relevant state. This will require a model that includes more information than a model of the static structure. E.g. things like activation state, selection etc must be included. Ideally, this representation should be independent of the toolkit, so that the same model instance may be used by SWT- and AJAX-based UIs. This also means that there must be a mechanism for adapting the "logical" EMF model to a specific toolkit. Perhaps this will be the role of XSWT/EXSWT, i.e. instead of mapping directly from XML to GUI, (E)XSWT will map from (an) EMF (model) to GUI and keep them synchronized.
- EMF annotations may play a role in supporting the mapping from EMF to widgets. E.g. a Text EClass may model the SWT Text widget, and the logic for mapping between them partly described by EMF annotations on the EClass, EOperations and EAttributes.
- Databinding will then be EMF to EMF, rather than EMF to SWT, with XSWT handling EMF to SWT.
- CSS could be used for deriving (defaulting) EMF values from other EMF values, as well as supporting the EMF to SWT mapping encoded by XSWT.
- The model should include some notion of activation state, like (dis)attached, (de)active, (in)visible etc. This is useful an several ways, e.g. for storing the workbench state, building the actual GUI lazily (a problem with large XSWT files) and for listening to (when an editor or view is activated).

Best regards,

Hallvard Trætteberg, Associate Professor at the Dept. of Computer and Information Sciences, Norwegian Univ. of Science and Technology.

P.S. Tom: You say you're going to Norway for your vacation. Since I'm Norwegian, please feel free to ask questions or even drop by!
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev