Re: [eclipse-incubator-e4-dev] CSS and declarative UI

[Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>]

Welcome Hallvard!  Thanks for your
interest and the brain dump.

We're going to do a pass of looking
at CSS technologies then will look at the various flavours of declarative.

> - It's not really clear what the role of EMF
will be. 

Speaking quite generally while we clearly
could apply it to a number of problems, we'll need to figure which would
provide the most benefit.  The modelled UI was a pretty obvious candidate.
 CSS may or may not be, I'm not sure if there's much to model in there
if we adopt some existing framework in which case its a matter of writing
the code to translate the CSS tree to SWT calls.  For declarative
work it seems to make sense since you model the abstract declarative tree
then EMF gives you the serialization to XML, etc.  I just don't want
EMF to be the hammer for which everything starts looking like a nail. 

> One possibility is to use 
> it as the runtime representation of the UI, so that a serialization
and 
> subsequent deserialization of it is enough to restore the relevant
> state. This 
> will require a model that includes more information than a model of
> the static 
> structure. E.g. things like activation state, selection etc must be
included. 

We already have a mechanism for saving
state between sessions.  OK an EMF one might be nicer but its competting
against an existing working code base which people understand how to program
to.  Tough sell and a tonne of work for ...?  I'd rather see
it applied to problems we have no solution for at present.

> Ideally, this representation should be independent of the toolkit,
> so that the 
> same model instance may be used by SWT- and AJAX-based UIs. This 
> also means that 
> there must be a mechanism for adapting the "logical" EMF
model to a specific 
> toolkit. 

Well, this is a long discussion.  I'm
skeptical at being able to come up with a single model which gives one
highly configured SWT and AJAX widgets both. In my experience you always
end up with something lowest common denominator. The current strategy is
to take existing high value widgets (e.g. styled text) and convert them
to _javascript_ and Flex, thus you have same API.  Generally the desktop
and web UIs are going to be different anyway (different users, workflows,
etc) so a common representation tends to be less beneficial than it'd seem
at first glance.

> Perhaps
this will be the role of XSWT/EXSWT, i.e. instead of mapping 
> directly from XML to GUI, (E)XSWT will map from (an) EMF (model) to
> GUI and keep 
> them synchronized.

This suggests that every call to SWT
would need to trigger (costly) synchronization code to keep the model up
to date. I don't see that one flying.

Also I'm not sure of the goal here.
 Why keep a model in sync with the real thing if I now have the real
thing?  When would I make calls to the model rather than direct calls
to SWT?  What's it buying me?  Either the model is an exact model
of the widget, in which case once you have the widget why do you still
need the model, or its an abstraction and no longer 1:1/onto, in which
case its likely there is information loss in one direction so not reversable
to the other (e.g. one SWT widget state resulting which could result from
many possible combinations of model state).

> - Databinding will then be EMF to EMF, rather
than EMF to SWT, with XSWT 
> handling EMF to SWT.

I'm getting a little lost.  Databinding is good
for keeping my domain model (not necessarily an EMF model, maybe just some
Java code) in sync with the UI. EMF to EMF implies I have models of models
(?).

> - CSS could be used for deriving (defaulting) EMF values from other
> EMF values, 
> as well as supporting the EMF to SWT mapping encoded by XSWT.

Ayyyeee, I'm getting lost in the hall
of EMF mirrors!  :)   You're proposing databinding from EMF to
EMF and CSS from EMF to EMF... I really am lost, what are we trying to
do here?

I see two choices for CSS:

1) Its applied directly against the
widgets.  This makes styling very literal, with the notion that you
can only make intelligent styling decisions if you know the actual properties
of the thing that draws on the glass.
2) Its applied against the UI model
(the Eric/Tom/Ed model).  This makes styling more abstract, potentially
reusable since you can swap the resulting widget type via factory change
with the styling preserved.

I like (1) for its literallness.  You
see the widget, know how each change will look on the glass.

What I like about (2) is it maybe gives
us a place to capture workbench level notions things like editor vs. view
stacks which are indistinguishable at the SWT level, and make styling decisions
based on that app framework state.  So (2) styles against how we use
the widgets, not the widget classes.

Best Regards,
Kevin