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

[Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>]

Great discussion guys.  I'm only
beginning to understand this area and the thread has been helpful.  Actually
my hope for the roundup is exactly this kind of shared understanding of
the technology, and some common view of the goal.

> 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.

Hallvard, I admit that I know nothing
of your research so I'm just going to speak quite generally, which may
not at all match what you're doing:

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.  The buck stops there.  Either you can have
list of strings, or a list of rendered strings plus images, or owner draw
... its in the capabilities of the widget and the only way to get stuff
on the screen.  In fact one can regard SWT as this exact toolkit independent
model (if we think toolkit=platform) because it attempts to isolate you
from platform specifics, thus the SWT list widget is already that abstraction
of the concept of a list widget across all platforms.  It just happens
to be API based, not declarative. 

My concern is that inevitably when you
go to an abstraction, you inherently lose some fidelity.  Maybe some
capability of a particular system you care about (in this case, SWT) can't
be expressed because your model is a common subset.  Or, the model
is a superset, in which case you write in the hopes of something happening
which doesn't on your particular platform.  We often see the former
case and sometimes the latter in SWT.  Since I've already lost fidelity
in SWT vs. the platform, I'm hesitant at losing more through another abstraction.

Yves, I have a similar concern around
the use of XAML since I may lose fidelity in going to SWT, but that's perhaps
more a statement of my ignorance of XAML.

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.

So I question, why do I need yet another abstraction?  I guess it
would let me go to Swing, which personally I'm not interested in. Maybe
it would allow me to go the web, but SWT is going to do what it always
does and treat it as a platform.  Unless you believe there is an inherent
flaw in doing so which a common abstract model solves?  I suppose
it could allow me to reuse parts of UIs (e.g. some pre-canned wizard pages),
but in my experience you always roll a UI that is specific to a problem
area.  Finally, it allows me to escape a particular programming language,
(Java, yeah!) but I think I get that from the declarative aspect, not the
common abstraction.  What am I missing here?

> 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>

Regards,
Kevin

Hallvard Trætteberg <hal@xxxxxxxxxxx>
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx

11/05/2008 09:00 AM

Please respond to
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>

To	E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
cc
Subject	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
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev