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
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
