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: [email protected] [mailto:[email protected]] 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. So, what about it? Regards, Dave Orme On Wed, Sep 2, 2009 at 3:30 PM, Boris Bokowski <[email protected]> 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 [email protected] 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
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
