RE: [eclipse-incubator-e4-dev] Declarative UI

[Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>]

Hi Yves,

You're absolutely right, extensibility
is very important.  When comparing we should also ask, "OK now
I have this Nebula widget...".

Looking forward to your SWT mapping,
this will help to make the discussions concrete.

Regards,
Kevin

"Yves YANG" <yves.yang@xxxxxxxxxxx>
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx

11/10/2008 04:17 PM

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] Declarative UI

Kevin,
 
>The practical me likes (A) since
the benefits are clear and you don't need to think too deeply about the
model (this is a feature). 
>The
theoretical me likes (B) since I really love the notion of elevating the
task of programming beyond the mostly administrative task of 3GL programming.

I agree with you. I have noticed
another issue I practically ignored before: the extensibility. There are
a lot of components developed on top of SWT. My concern is how these components
can be integrated in this solution easily: better directly and transparently.

 
The B)
introduces a new programming API to manipulate the abstract model. 
 
Just for your information,
I’m exploring the possibility of using XAML to mapping directly with SWT/JFace
by developing a plugin as requested by Dave. Let’s the facts speak for
themselves. 
 
Soon (maybe in ESE), I can
show what it is capable and also its limitations. In this plugin, we focus
on several issues:
1.
      Dynamic
mapping with SWT/JFace
2.
      Integeration
with JFace DataBinding
3.
      Extensibility
and Re-usability
4.
      Integeration
with VEX of eclipse SLDT to provide a User-Friendly editor
 
I have put an entry in http://wiki.eclipse.org/E4/DeclarativeUI/XAML_Roundup#Current_License
with some samples. All examples in this page are developed and work. 
 
If someone likes to look it
in detail, please drop me line. 
 
Best regards
Yves YANG

---

From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
[mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On Behalf Of Kevin
McGuire
Sent: Monday, November 10, 2008 8:57 PM
To: E4 developer list
Subject: RE: [eclipse-incubator-e4-dev] Declarative UI
 

Hi folks, 

I just got caught up on this great thread. 

Hallvard, good summary. 

As another cut through the space, this is what I'm hearing, two extremes,
both compelling: 

A) A "literal" model of the UI. 
  
You know the target is SWT and the model reflects exactly that.  If
you know SWT, you can guess pretty easily what to put in the angle brackets.
 You get a serialization/deserialization format.  For large UIs
it can reduce your total Java code in-memory footprint.  You can do
things like build up the model in memory first, then create the widget
structure as a walk through the model.  You can build that model from
reading the current widget tree.  It allows you to avoid widget reparenting
issues by reading the widgets, destroying them, then recreating them elsewhere
(e.g in a second workbench window).  It facilitates GUI builders.
 Its a good basis from which to build other model abstractions (see
below). 

B) An abstract model of UIs (say, functional).

Here you want to get "above" the level of the widgets.  The
domain of discorse is maybe one of data display and user interaction, or
common UI solution patterns, not widgets and layouts.  This might
be a model of UI requirements and capabilities that get translated into
concrete widgets. For example, "I need a table, the user will add
and remove from the table" generates a table widget with add/remove
buttons.  This can be handy if you are generating a lot of UI panels
for say pages of entry fields, dialogs, and wizards.  It also provides
a natural way to bridge to different widget sets (e.g. gen to SWT, gen
to web).  You likely forgo some ability to tweak the UI but gain in
speed of authoring, easier refactoring, etc.  You also get free consistency
in your UI since functionally equivalent UI areas get gen'd the same.  Such
models are much more contentious though since you must convince yourself
you're modelling the right thing, and that either the limitations of the
model are acceptable or there's some "escape to assembler" path.

These two aren't mutually exclusive.  If you're doing (B), its probably
handy having (A) so you can do a model to model transformation as the path
to instantiating the actual widgets.

The practical me likes (A) since the benefits are clear and you don't need
to think too deeply about the model (this is a feature).
The theoretical me likes (B) since I really love the notion of elevating
the task of programming beyond the mostly administrative task of 3GL programming.

I need to learn more, but it sounds like XSWT is close to (A) although
you might not get everything currently like the live model.
Again I need to learn more, but is XAML much more than (A)?  It seems
less than (B) since I'm still talking about a literal UI with a certain
layout, labels, etc., although perhaps in a more general manner.

Regards, 
Kevin

"Yves YANG" <yves.yang@xxxxxxxxxxx>
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx

11/09/2008 11:16 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] Declarative UI

 

Hi Hallvard,

Regarding the comparison between XAML and XSWT, I agree with you. 

As for the goals, I think the goal (1) is a wrong goal for XML since there
are other formats are more compact like JSON, or binary directly. The goal
(2) is necessary as declarative UI language. The goal (3) is rather than
a
model in memory. I vote (2) + (3). 

yves
-----Original Message-----
From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
[mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On Behalf Of Hallvard
Trætteberg
Sent: Sunday, November 09, 2008 4:54 PM
To: E4 developer list
Subject: Re: [eclipse-incubator-e4-dev] Declarative UI

Kevin,

Kevin McGuire wrote:

> Shall I try to pick a time in say about two weeks?

OK for me. It has been mentioned that some will meet at ESE. I'm going
there

myself, but haven't yet received a confirmation about the e4 symposium.
I
was a 
day late with the position paper (didn't post here but to the email address
found in the call), but still I hope to be allowed to attend.

> Specifically, while it would be good to have presentations on XSWT,
XUL,
etc.
> I think the agenda has to be more around approaches and goals.

In the last postings (Yves Yang and David Orme), there has been some
comparison 
of XML notations (XAML and XSWT). As pointed out by Yang, XSWT is perhaps
more 
targeted at serializing SWT. Or rather, it is a description of how to 
(procedurally) _build_ a specific SWT UI, while a XAML is a (declarative)
model 
of the (initial) _state_ of a UI. David and Yves, do you agree? Whether
or
not 
this difference is important, depends on the goal.

If the goal (1) is a compact notation from which to render an SWT UI, I
think 
XSWT's approach (guessing the meaning of names, based on type information
acquired by means of reflection) is best. If the goal (2) is a model for
describing the state of the UI, a model which lends itself to generation,
transformation and other processing, something XAML-like may be best. A
third 
(level) goal (3) is having a "live" model which is kept in sync
with the
running 
UI. Such a model can provide a more uniform, API-independent way of
manipulating 
 and listening to the UI.

These are different goals I can identify, and that I hope is a constructive
contribution to this discussion.

Personally, I favor goal (3), a model supporting live syncing with the
real
UI. 
If we design this model using EMF, we get scripting and databinding for
free
(it 
already exists). I think we can still use XSWT, XAML and other XML languages
as 
concrete syntaxes, since they may be more usable than EMF's native one.
The
XSWT 
processor can we thought of as a compiler that generates the EMF model
as 
intermediate code, instead of building the SWT UI directly. It should also
be 
possible to generate Java code from the EMF model, or perhaps compile it
directly to bytecode, for use in mobile applications.

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