Re: [eclipse-incubator-e4-dev] Initial discussion onthe'modelled'workben

[Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>]

>>One thing
that nobody's mentioned yet are the CSS requirements; if we get this right
(and we must) then almost all of the 'properties' we're talking about modeling
here (tab style, min/max
>>buttons, colors/fonts...perhaps even the SWT widget
to render with) will be coming from the styler and won't even -be- a part
of the ModelElement's data.

Eric, I'm not sure about that statement.
 The properties that the CSS manipulates are to me attributes of the
model.  CSS is just a markup for specifying how to apply changes to
the defaults, just as they are already properties as described by HTML.
 The "styler" would be a programmatic way of achieving the
same thing.

In that sense I agree with your other
statement that either going programmatically against an API or via markup
such as CSS or whatever, it must eventually go through the model API and
be functionally equivalent.

You used the word "requirements".
 At this initial junction the only CSS'ish requirements I can see
is that the model elements have optional ID and class.  In this case
by "class" we mean a usage classification supplied as part of
the assembly description. Just like I can have HTML <li> but assign
two different instances two different classes to denote their usage semantics
(e.g. customer list vs. product list).  

After that there's consideration for
CSS pseudo-classes, which are really just state descriptions (e.g. link
is selected or not), but I've not thought a lot yet about our mapping to
them.  From my initial investigations I get the sense that the set
is closed, part of the CSS spec rather than just surfacing HTML properties,
so don't know if you're expected to be expanding the set with existing
CSS parsers. Perhaps Yves has more thoughts on this.

Kevin

"Eric Moffatt" <emoffatt@xxxxxxxxx>
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx

04/06/2008 01:35 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] Initial discussion        onthe'modelled'workbench UI

Tom, have no fear..I'm not at all closed on discussions about the API.
I was just going to start them -independently- of whether or not EMF is
a suitable candidate as 'Model Server' (we should likely start a different
thread for this)...the question remains; can EMF emulate the current API
and, if so, at what cost?

Your comment "Eric's model is perfectly suited for scripting guys"
is true. Given that this is a design requirement I don't think that it's
inappropriate. I realize that there's a trade-off between an unbounded
and untyped 'bag of properties' and a formalized full on completely meta-modeled
structure. The main problem I see with the fully modeled approach is that
I fear that it'll make our users life more difficult. If they want to use
ModelElement as the basis for -their- domain object will they be required
to get into writing an ECore extension to the ETreeModel metamodel (or
whatever the EMF equivalent is) n order to use the JFace viewer ? I'd be
more than glad to find out that this is YAGF (Yet Another Groundless Fear...;-).

The 'loose' approach is based on a concept of 'common properties'; -any-
ModelElement that contains a GUI_LABEL and/or a GUI_IMAGE property can
be hosted in a tree (or a menu, toolbar or CTabItem) making it very simple
for clients to use for -their- work.

My bet is that we're going to end up in the middle somewhere, completely
untyped/bounded is -too- loose. Perhaps one approach is to provide meta-information
on a 'per property' basis (i.e. a property would have to be 'registered'
(including meta info) against a 'type' before it can be set in that type.
I was expecting to do this using an 'exemplar' model; you'd 'register'
a ModelElement whose current structure (its properties and their data types)
represent the valid properties (and their defaults?) but API might be ok
as well (I'm not really anti-api, I just think if should be generated from
the model...;-).

This remains a primary concern of mine; the end result must be easily consumable
downstream, both to understand and to extend. I found it interesting when
initially looking at JSON that it's rate of acceptance is high because
it's -simpler- than other infrastructures that it was competing against..perhaps
they're onto something.

One thing that nobody's mentioned yet are the CSS requirements; if we get
this right (and we must) then almost all of the 'properties' we're talking
about modeling here (tab style, min/max buttons, colors/fonts...perhaps
even the SWT widget to render with) will be coming from the styler and
won't even -be- a part of the ModelElement's data.

Whatever we end up using (both as API and as implementation) the only two
things that someone's going to have to use a big stick to beat me off of
are:

1) -All- GUI changes take place as responses to an observable model. Otherwise
it's not MVC

2) The protocol currently enforced in the ControlFactory's 'createGUI'
and 'disposeGUI' methods be the -only- path through with rendering elements
are managed. This is needed to enforce the CSS styling (as well as a way
to maintain sanity in the world...;-). Tom, the reason that the 'clientArea'
gets added to the 'contents' as well as being its own property is to get
the rendering for take place in the ControlFactory's 'processContents'
part of the protocol).

time for lunch,
Eric



On Sat, Apr 5, 2008 at 11:09 AM, Boris Bokowski <Boris_Bokowski@xxxxxxxxxx>
wrote:
Kevin wrote:
> At the risk of killing momentum, I'd like to suggest that this
> investigation would work best if someone on the platform team (yes,
> I'm looking at you Eric <g>) were involved to whatever degree
it
> made sense.

I am a little surprised - Kevin did you realize that Tom
is *already* a
member of the Platform team, as a Platform UI committer?

Yes, Eric should be involved in this, but I also think that Tom should
be
allowed to do the same thing Eric has done - produce some experimental
code
to be used in the discussion (code speaks!) - and I have therefore
nominated Tom as an e4 committer.

For higher-bandwidth communication, we can use the #eclipse-dev channel
(see http://wiki.eclipse.org/IRC).
I know that both Eric and Tom can be
found there regularly. Please remember to post occasional updates to the
mailing list as well...

Boris

_______________________________________________
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