[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
