Hi Dave,
You given a very good point.
The serialization is one aspect. Another aspect is dynamic
programming: event handling and dynamic UI. XWT relies on existing APIs:
SWT/JFace. This is why XWT is SWT user-friendly. If we put XWT on top of TM, we
have to TM’s API. The compatibility of XWT with exiting will be lost.
Best regards
Yves YANG
From:
e4-dev-bounces@xxxxxxxxxxx [mailto:e4-dev-bounces@xxxxxxxxxxx] On Behalf Of David
Orme
Sent: Thursday, September 03, 2009 5:25 AM
To: E4 Project developer mailing list
Subject: Re: [e4-dev] TM and XWT
I'm going to throw my two pence in for the compatibility
argument, but not in a way that has been discussed yet in this thread, but
which was discussed as early as the E4 Summit.
To me, XWT, is simply a serialization format. It could
be a serialization format for SWT widgets like it is now, or it could be a
serialization format for EMF objects like those used by Wazabi or TM. I
note that in the context of Visual Editor, XWT is ALREADY a serialization
format for an EMF model--VE's Java EMF Model (JEM) that forms VE's model tier.
Adding serialization to/from XWT and a second EMF dialect doesn't seem
like a huge stretch to me.
So I still think this is a good idea, for three reasons:
1) Coming from the point of view of Patrick Paulin, newbies
can learn XWT to start and graduate to EMF and TM (or Wazabi) later. It
gives newbies a smaller surface area to learn. And I really appreciate
the work that Yyves has done to make VE work with XWT; we should leverage that
if we can.
2) Back at the E4 summit, we liked the idea of using EMF all
the way from the glass to the back--all the way up and down the stack. I
still like that idea. Modeling using POJOs seems so early 2000's (and
soon it will be 2010). ;-)
3) Ed Merks said it was a good idea. ;-) OK, you could
scratch this as a reason if you like. <grin/>
Yyves, I'd love to see your work live on top of either of
(TM | Wazabi). Hallvard, I think that TM has some really nice ideas, but
also really support your idea to try to merge with Wazabi if possible.
On Wed, Sep 2, 2009 at 3:30 PM, Boris Bokowski <Boris_Bokowski@xxxxxxxxxx>
wrote:
Hi Yves, Hallvard, and everybody else,
Thank you for the interesting discussion so far. :-)
A couple of comments:
1. We don't need to pick a "winner" or a "loser". It is
perfectly fine to develop technologies in parallel, in fact having some
competition as to who solves a problem best is probably good (for some time).
For any component in the e4 project, there are several possible exit strategies
(ignoring obvious ones like "stop working on it"): graduate by
merging it into the Eclipse SDK, graduate within the e4 project, or graduate by
moving to another host project. Just to give concrete examples for the last
option, Nebula would probably be a good host project for XWT, and perhaps PMF
would be a good host project for TM.
2. Fragmentation is not good, in the long term. If after careful consideration,
the differences between XWT and TM turn out to be minor, or just a matter of
personal taste, it would be preferable to make an attempt at merging the two.
Clients will be confused as to which one they should choose. I don't know the
technical details, but if both TM and XWT provide a 1:1 mapping to SWT widgets,
shouldn't it be possible to have a 1:1 mapping between TM's EMF model and XWT's
XML files? It looks like https://bugs.eclipse.org/bugs/show_bug.cgi?id=260289
is a good starting point for investigating this.
3. Real clients are more important than theoretical advantages of one
technology over the other. Based on my limited knowledge on who uses which
framework, Wazaabi seems to be ahead of both TM and XWT at this point, but I'd
love to be proven wrong...
4. A few of the comments in this discussion came across as being protective of
your respective technology, and not as cooperative as I would like them to be.
Furthermore, both XWT and TM currently score pretty low on the "committer
diversity scale". It would be so much better if you could combine your
efforts and build something that is greater than what could be built by just
one of the parties involved.
5. Independent of this discussion and whether consensus can be achieved, I
agree with McQ that pluggability is a good thing. I wouldn't want to see
anything in the e4 Workbench code that makes it easier to use one declarative
UI toolkit over another. It should be equally easy to contribute views,
editors, dialogs, preference pages etc. whether they are written by hand, or
built using TM, XWT, Wazaabi, PMF, or other such frameworks.
Btw, there will be an e4 Symposium at Eclipse Summit Europe (Ludwigsburg,
Germany, October 27-29): http://www.eclipsecon.org/summiteurope2009/sessions/sessions?id=981
Hope to see you there!
Boris
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
Internal
Virus Database is out of date.
Checked by AVG - www.avg.com
Version: 8.5.392 / Virus Database: 270.13.58/2306 - Release Date: 08/16/09
06:09:00
|
