RE: [e4-dev] Declarative UI

["Yves YANG" <yves.yang@xxxxxxxxxxx>]

Hi Tom,

> What I still say---I discussed this yesterday with Kevin on IRC---is that
a 1:1 declarative UI definition works as long as you don't mix in CSS.  But
at this very moment 1:1 fails because one might be needed to create certain
effects to modify the Widget-DOM, e.g., nest a control in an artificial
composite to show a shadow border.

I cannot see any problem of 1:1 declarative UI with CSS. If you change the
Style, you can simply recreate the entire tree or view. 

With an abstraction layer, you should have the same problem. In SWT, some
parameters must be provided during the creation. If you want to change it,
you have no way to do it on "live" (keep the same SWT Widget). The only
solution is "delete it and recreate it". It is what we do in eFace and XWT.
I cannot see any problem with this solution. 

Best regards
Yves YANG
Soyatec - Eclipse OutSourcing & XAML for java
http://www.soyatec.com
Tel: +33 1 60 13 06 67
Mobile: +33 6 20 74 39 45
Fax: +33 9 58 07 06 67

-----Original Message-----
From: e4-dev-bounces@xxxxxxxxxxx [mailto:e4-dev-bounces@xxxxxxxxxxx] On
Behalf Of Tom Schindl
Sent: Friday, December 19, 2008 5:38 AM
To: E4 Project developer mailing list
Subject: Re: [e4-dev] Declarative UI

[...]

> 
> I discussed this with Tom at ESE, and I agree that UFace technically
> could have this role. UFace contains a lot of relevant and important
> code for implementing the rendering logic, i.e. controlling the
> life-cycle of toolkit objects and managing binding. However, consider
> the state at runtime if UFace as a whole is used. You will have
> EObject <-binding-> UBean <-binding-> SWT widget, instead of the simpler
> EObject <-binding-> SWT widget.

Your observation is completely right and it looks like you hijacked my
dreams. Yesterday, before going to bed, I thought about this and about
how I could define UFaceKit using Ecore.

Currently all this is floating around in my head but I have no final
idea of how I could make the UFaceKit way of doing could be programmed
in EMF.

Here are some of the problems I haven't solved (yet):
- SWT-Widgets require a parent at creation time where as EMF-Object are
created with a no-arg constructor

- How could I satisfy all the needs of constrained devices that don't
want to have a live model and to which we need to port EMF; my main
target is GWT => I already ported it once but this is a huge task...

What I still say---I discussed this yesterday with Kevin on IRC---is
that a 1:1 declarative UI definition works as long as you don't mix in
CSS.  But at this very moment 1:1 fails because one might be needed to
create certain effects to modify the Widget-DOM, e.g., nest a control in
an artificial composite to show a shadow border.

Still we all agree that the widget hierarchy from the outside should not
change just because I create a shadow-border, for the user.

You could argue that SWT should take care of all these features we
wished were there, but IMHO this is not the task of SWT; it should give
us a clean and concise abstraction of the native widgets no more nor
less. By pushing features like shadow border down to SWT we only make
SWT more bloated and this not what any of us want.

So what we need is a higher level of abstraction as thin and as concise
as possible. If UFaceKit could give first ideas to make this possible, I
would more than welcome all of you to step in and help us to get there.

We are open for every suggestion and contributer /committer who helps us
to bring this project one step forward and make it usable to all of us.
I might have to mention that UBean-API and all things built on it are
inspired by EMF but exposing less meta-data then EMF does, e.g., we
don't care a but operations...

A UBean simply provides the following things:
- Reflective Attribute Interface by copying EMF-eSet/eGet
- Generic Event-System by copying EMF's notifications
- Access to Feature-Types and Features (EMF-ePackage)

I don't know if by restricting ourselves to those features (e.g., all
those specialized EMF-Lists, EOperations, ...) we could extract a new
smaller EMF-Module we could use....

So here's my (revised) design of how the current work in UFaceKit can be
exploited to use EMF (as it is now without any changes to extract
slimmer super-classes/interfaces)

                        UFaceKit-Interfaces
                               ^
                               |
         ---------------------------------------
         |                                     |
 ConstraintedDevice                AbstractUFaceKitEcore
         ^                                     ^
         |                                     |
----------------------             -----------------------------
|          |         |             |              |            |
Android   eSWT      GWT         SWTEcore     SwingEcore      QTEcore


Currently UFaceKit has implementation for SWT, Swing and QT and the only
missing piece is to create the AbstractUFaceKitEcore and the let the
current concrete implementation inherit from them. Once we could
Parallel-IP approval I'll check in the current sources and switch the
design (yeah I just made this decision :-)

Tom

-- 
B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl                               leiter softwareentwicklung/CSO
------------------------------------------------------------------------
eduard-bodem-gasse 8/3    A-6020 innsbruck      phone    ++43 512 935834
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev