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