Welcome, Hallvard! To others: Hallvard rocks. :-) He and I have been working together on XSWT (on and off) for over a year.
Generally: All good points. I'm particularly interested in seeing if we can find a good solution to making an EMF-based XSWT implementation into an open system, as you point out, so that we don't lose one key benefit of XSWT: that it works with all current and future SWT controls with zero extra effort. Regards, Dave On Mon, Jun 30, 2008 at 6:55 AM, Hallvard Trætteberg <[EMAIL PROTECTED]> wrote: > Hi all, > > I've just become member of this list, so let me first introduce myself > before making some comments to the "CSS and declarative UI round up" > thread". > > I'm a researcher working in the field of model-based user interface design. > In my thesis I developed a UI dialog modeling language called diamodl (see > http://www.idi.ntnu.no/~hal/research/diamodl/<http://www.idi.ntnu.no/%7Ehal/research/diamodl/>) > and over the last years I've been working on Eclipse-based tools for it, > both editor (GMF) and runtime (EMF, Databinding, XSWT/SWT and Javascript). > Diamodl essentially models flow of data in a data binding graph and > activation of dialog elements based on a State charts. Thus, the model can > be thought of as glue between the application data and the toolkit, i.e. an > abstract/logical UI model as opposed to a model of the actual widgets. > > So, what is the relevance for e4? I see several: > - I've been committing code to XSWT the last years, to make it more usable > for my diamodl runtime, like XSWT stylesheets, javascript, more flexible > XML. (Unfortunately, there is no release with these features, but the code > is in CVS.). Based on this work, I have some thoughts about how it may be > improved to include other hierarchical and related data, like view > structures and data binding graphs. > - Scripting support has been mentioned as important for e4, and Rhino has > been integrated with both EMF and XSWT as part of my work. > - Since the diamodl runtime is based on so many relevant technologies, > diamodl's concepts (variables for data, computations for data > transformations and connections for data bindings) may also be relevant for > a model-based e4. > > Some more specific thoughts on the issues in this discussion: > > Using EMF for modeling the GUI, what does that entail? > - One of the advantages of XSWT is that it does not rely on a closed model, > since it uses reflection for looking up classes, constructors, methods and > properties. If we go for an EMF model, we must make sure it is easy to > extend it at runtime, e.g. by loading an EMF fragment for a new widget or > generating a model fragment based on reflection (possibly pregenerated). > - It's not really clear what the role of EMF will be. 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. 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. 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. > - EMF annotations may play a role in supporting the mapping from EMF to > widgets. E.g. a Text EClass may model the SWT Text widget, and the logic for > mapping between them partly described by EMF annotations on the EClass, > EOperations and EAttributes. > - Databinding will then be EMF to EMF, rather than EMF to SWT, with XSWT > handling EMF to SWT. > - 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. > - The model should include some notion of activation state, like > (dis)attached, (de)active, (in)visible etc. This is useful an several ways, > e.g. for storing the workbench state, building the actual GUI lazily (a > problem with large XSWT files) and for listening to (when an editor or view > is activated). > > Best regards, > > Hallvard Trætteberg, Associate Professor at the Dept. of Computer and > Information Sciences, Norwegian Univ. of Science and Technology. > > P.S. Tom: You say you're going to Norway for your vacation. Since I'm > Norwegian, please feel free to ask questions or even drop by! > _______________________________________________ > eclipse-incubator-e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev >
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
