Here is the complete example in XAML
In case, if you have your owner layout
named as ui.MyGridLayout, the code will be:
On Behalf Of David Orme
Sent: jeudi 6 novembre 2008 18:11
To: E4 developer list
[eclipse-incubator-e4-dev] Fw: Declarative UI roundup?
Since I won't ask someone
to do something I won't myself do, :-) here's a slightly-enhanced Hello, world
in XSWT, eliminating the XML boilerplate and imports:
<label text="Hello, world"/>
This is functionally equivalent to:
Label label = new Label(parent, SWT.NULL);
Text text = new Text(parent, SWT.BORDER);
text.setLayoutData(new GridData(GridData.FILL_HORIZONTAL |
(This actually translates to:
= new GridLayout();
gl.numColumns = 2;
Label label = new Label(parent, SWT.NULL);
Text text = new Text(parent, SWT.BORDER);
GridData gd = new GridData();
gd.horizontalAlignment = SWT.FILL;
If you could translate this to XAML, Yves, that might be a useful place to
On Thu, Nov 6, 2008 at 8:02 AM, Yves YANG <yves.yang@xxxxxxxxxxx> wrote:
So let's compare the two directions: abstraction model UI and
1. SWT Centric
This approach consists of mapping directly from XML <->
SWT. It is true SWT is already an abstraction of the different UI technologies:
Win32, GTK, etc. But it is low level abstraction: UI Widgets. It doesn't cover
more advanced concepts.
Could someone tell me why Eclipse invents a new UI Library
SWT, instead of using Swing, which is already cross platform? From my point of
view, SWT respects the native Look and Feel, particularly, in Windows. And Swing
had some problems of performance, ugly look and complexity in development. This
is a good example of courage to replace the out-of-date solution by a new one.
Are we in the same situation? SWT is designed mainly to create the UI via
programming. It is created several years ago. Its API doesn't full respect
neither the model constraint, non JavaBean specification. Using it as main
model, the new component will inherit its limitations and we have to add
outside components to support other features such as style, data binding. Does
it become a hybrid framework?
Since the birth of SWT, the UI technology evolves quickly to
markup language. Microsoft has the courage to give up the Win32 and invent a
new component-based framework WPF for providing common and full integrated UI
platform not only for Developer, but also for graphic designer and business
analyst. It focuses on content presentation, instead of low level basic UI
widgets. It really simplifies the UI Development.
I think SWT should stay where it is designed for.
2. Abstract UI model
Simply, it will give us a new land with maximum freedom to
develop a complete, extensible UI "Presentation" Framework.
Just a thought
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.
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:
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.
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
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
this solved to a great degree through the use of
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
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
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
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
> | |
| Transform (XSLT, ....)
SwtXL => EMF-Modeled SWT-API
> 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
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
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
the UI through Ecore has great
> I've already tested this approach in a
project I had named EXSWT the
> only thing missig there was the Ecore-Model
for EXSWT .
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.
eclipse-incubator-e4-dev mailing list