Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] TM and XWT
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 <yves.yang@xxxxxxxxxxx>
> yves.yang@xxxxxxxxxxx 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
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>


_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev

Back to the top