Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] Declarative UI 
Hi Tom,

I am fully agree with you about the need of a abstraction layer.
Regarding the requirement of a parent during the creation phase of SWT widget (and not in SWING widget), in Wazaabi 2.0, the SWT widget is embedded in a View (the V of the our well known MVC ;-) ). I borrow from GEF high level abstract classes like EditParts & EditPartViewers, etc.... With such a mechanism , the real widget creation is delayed to the latest moment as possible. The next step, after view creation is to apply on it 'visual effects' from the model. This mechanism allows us to reparent widgets (even containers), to unify creation process with SWING, to change on the fly a widget by another one (skinning) --to be honnest, this last step is more theory than practice, I need to test it :-) Regarding the shadow border example, the view concept allows us to define a more complicated widget if needed without overheading our model. The major drawback of this approach is to know where to place graphical behavior in the view or in the model. Then now, there is 3 (instead of 2) places where to put graphical behavior : concrete metamodel, abstract metamodel & view definition. 

Olivier


Tom Schindl a écrit :

[...]


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

Back to the top