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
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
