Re: [eclipse-incubator-e4-dev] Fw: Declarative UI roundup?

[Hallvard Trætteberg <hal@xxxxxxxxxxx>]

Kevin,

Comments below:

> I find this theoretically cool but with my practical hat on I'm trying 
> to understand the benefit this added abstraction buys us in Eclipse.  My 
> original thinking was that the declarative language should map 1:1 to 
> SWT, because its SWT that actually does, well, the useful stuff.

I gave some background to explain where I'm coming from and what my experience 
is. Think of my model as a graphical model of how widgets are connected using 
databinding. I use XSWT for the widgets themselves, which as David says, is as 
close as you can come to SWT using XML.

I didn't mean to suggest using the abstract model in Eclipse, at least not in 
the platform! But based on my experience with XSWT, I have opinions about 
requirements for an XML-based representation of SWT.

> Thus my thinking was perhaps along the lines Tom outlined: a declarative 
> model written against SWT, exposing accurately the capabilities of SWT 
> but in a serializeable format instead of Java code, providing a model 
> which facilitates mapping to other declarative models.

As David wrote, this is XSWT: It uses reflection to be as close to SWT as 
possible, it is compact, it supports styles and scripting, it is easy to extend, 
we have plugins for rendering XSWT in a view, we have extended WTP's XML editor 
to make it more useful for editing XSWT.

However, XSWT's advantage is also its disadvantage: Since it uses reflection to 
be as close to SWT as possible, it does not have an explicit model/schema 
besides SWT's API. E.g. this makes it difficult to make the DOM "live" in the 
sense that updating it also updates the UI. I believe this specific problem can 
be fixed, but I would rather use EMF than XML.

>  > 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.
> <naiveQuestion>Isn't this solved to a great degree through the use of 
> databinding?</naiveQuestion>

To some extent, yes, but it only handles data, not activation/deactivation of 
widgets, moving them around etc. The workbench model that people are working on, 
based on Tom's initial experiment, shows the power of using EMF for describing 
the structure and keeping the concrete UI up-to-date.

Model: What I want is a declarative representation of the UI, based on an Ecore 
model that is a slight abstraction of the current toolkit (SWT), but close 
enough to be easily supported/implemented by it. (Perhaps UFaceKit is this 
slight abstraction?). The model should focus on the standard structure of all 
toolkits, particularly the parts you would like to manipulate to change the UI 
at runtime:
- widget hierarchy
- visibility and enablement of widgets
- value attributes of widgets, like label, text, selection
- standard visual attributes like color, icons, and styles containing such

If we pay attention to details, particularly naming, the mapping to SWT 
shouldn't be difficult or costly. I think XSWT's heuristics will be useful, and 
EMF annotations can be used to avoid guessing.

Extensibility: The model should in some way support adding toolkit-specific 
vocabulary, so we can use toolkit-specific data and constants when we need to, 
to avoid losing fidelity. E.g. although most toolkits support attaching layout 
to containers and layout data to each widget, the specific objects are fairly 
toolkit-dependent and we would like to be able to use those. Ideas:
- support this as part of a styling mechanism, i.e. use styling as hints to the 
toolkit-specific mapping.
- use EMF's support for XML anytype and wildcards at strategic places to add 
toolkit-specific data
- use reflection to generate part of the model

Databinding: I think such a model could support support databinding, including 
binding to Ecore data structures. It would be nice to support binding across 
plugin boundaries, e.g. binding the selection of an editor to the data shown in 
a related view. This may require exposing databinding attach points 
(IObservables), as a generalisation of techniques based on IAdaptable and 
ISelectionProvider.

Scripting: If Ecore is scriptable, the UI will be, too. I have already 
implemented good support for Ecore for Mozilla's Javascript.

Hallvard