Hi, Yves: "I think you should understand why XWT cannot be on top of TM."
How about build XWT on top of EMF? Maybe I should see some XWT sources. Adding a extra EMF layer may be not necessary for directly manipulating SWT. But this make your two team could joint your effect, And it make some high-level EMF manipulatings possible. Jin 2009/9/3 <[email protected]> > > [email protected] wrote: > >> > >> What's your definition of representation? I guess it is EMF object which > >> defines UI. With EMF, you have to deal this new layer. And of course, > >> you > >> need to a "live model". > > > > Both TM and XWT resources (files) are UI representations, based on EMF > > and XAML/XML, respectively. The fact that XWT doesn't need it once it > > has been loaded and the UI rendered doesn't change this fact. Tools that > > are used for editing must have it in memory. > > > >> In XWT, this layer doesn't exist. XWT can be considered as a simple > >> Loader, which read XML file and create immediately SWT widget. So we > >> don't > >> care of "live model" or precisely "live layer". It is always "live". > > > > What I think you mean is that the XWT representation doesn't exist in > > addition to the SWT object during runtime, once the latter has been > > built. You throw it away, and the application programmer uses the SWT > > objects for handling events and manipulating the UI. So it's SWT that is > > "live", not XWT. > > > Yes, it is REALLY simple. In general, we should keep simple. NetBean > doesn't the same way. > > > There are three kinds of advantages of a live representation (that I can > > think of at this moment): > > - It provides more flexibility, e.g. even if SWT doesn't support > > changing style bits, XWT could allow it and under the covers > > re-instantiate the SWT object > > I guess TM and XWT uses the name concept. > > > - It provides a higher abstract level or otherwise mentally cleaner or > > simpler model, e.g. a simpler class hierarchy, uniform styling model, > > etc. This is not that relevant for XWT, since it is SWT-oriented by > > design. > > We should split developers in two groups: UI Element provider and UI > Consumer. > > What you said is true for UI Element Provider. But for the UI Consumer, > XWT does privide also abstract level. For me, the most important is the > separation. > > I think you should understand why XWT cannot be on top of TM. > > Best regards > Yves YANG > > - The underlying representation (EMF or XML) may better support generic > > operations like copying hierarchies, visiting nodes, querrying, > > observing, persisting, transformations etc. > > > > Hallvard > > _______________________________________________ > > e4-dev mailing list > > [email protected] > > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev >
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
