All, There are a lot of information here, and I am really excited to discuss with you @ ESE. Let me just add one last comment. I have red a lot of things about the requirement to learn EMF and its complexity. But as far as I know, the Workbench is a live EMF-model isn't it ? And as extension provider we do not need to learn all the specificities of EMF to extend the workbench.
After all, I think that one key point of E4 is the ability to plug any technologies you want as UI: JavaScript, SWT, UFaceKit, XWT, Wazaabi and any other UI provider. Each of them, supporting different concepts and approach and I really believe that having such flexibility would be key a differentiator for Eclipse and RCP. Best regards and see you @ ESE, Sabri. 2009/10/14 David Orme <[email protected]> > Yyves, Hallvars, Olivier, et all: > > I also won't make it to ESE and just would like to chip in my support (that > I've said before) for XWT on top of something EMF-based like TM or Wazabi. > > The sooner this is reconciled, the sooner potential customers can start to > seriously download E4 and start kicking the tyres. > > > Best regards, > > Dave Orme > > > On Tue, Oct 13, 2009 at 1:30 PM, <[email protected]> wrote: > >> Hi Stefan and Patrick, >> >> See my comment below. >> >> > 2. XAML and WPF >> > You mentioned tools based on XAML. Tools that I know about (as >> Expression >> > Blend) are based on XAML+WPF. That's a difference. I don't think that it >> > makes sense to adopt WPF's widget model and even if one would do so, I >> > doubt that using Expression Blend for designing Eclipse UIs would be >> > possible. >> > >> > I agree that using existent standards is a desirable goal. However, in >> > case of XAML I can only imagine of taking concepts and use them >> (examples >> > mentioned above, maybe Binding syntax, too). Being 100 percent >> compatible >> > is not realistic. >> >> I understand the purpose of Patrick. I can give you another case. We are >> working on ESL project http://www.eclipse.org.esl (knwon as eclipse4sl - >> Eclipse tools for Microsoft Silverlight), which has an instant preview >> editor. The same editor is already provided in XWT. We can image to >> develop a common toolkit that works for for both just with different UI >> model. >> >> I agree with XWT can not be 100% compatible with WPF. It is exactly the >> position we take by now. It is the different between XWT and eFace. >> >> Thank both of you for giving the important feedback. >> >> Best regards >> Yves YANG >> > >> > Regards, >> > Stefan. >> > >> > >> > -----Ursprüngliche Nachricht----- >> > Von: [email protected] [mailto:[email protected]] Im >> > Auftrag von Patrick Paulin >> > Gesendet: Dienstag, 13. Oktober 2009 19:19 >> > An: E4 Project developer mailing list >> > Betreff: Re: [e4-dev] Why XML UI is important for us >> > >> > I'm glad to hear that the participants in this thread are going to get >> > together at ESE and work through these issues. Meeting face to face >> > often makes these discussions much easier :) >> > >> > Unfortunately I can't attend ESE, so I wanted to provide my input >> > here. I hope you'll consider these points when you're making final >> > decisions. In my opinion, there are really two questions here: >> > >> > 1. What should the default UI construction experience be for Eclipse >> > developers? >> > 2. How can we maximize the UI framework's power and flexibility to >> > allow for future innovation? >> > >> > My answer to #1 is that the default UI mechanism should be standards- >> > based and declarative. I've worked with and trained many RCP >> > development teams. These teams often struggle to learn the many APIs >> > that make up Eclipse RCP. The more we can incorporate familiar >> > solutions into RCP, the easier it becomes for teams to adopt it. Many >> > of the teams I talk to are very interested in declarative UIs, and I'd >> > say that most of them would be very happy with XAML + CSS. Remember >> > that this thread began with an RCP user saying how excited they would >> > be with a declarative UI. Please listen to these users. >> > >> > Choosing XAML as the default developer experience also allows us to >> > leverage existing resources. There are books on XAML. There are tools >> > that work with XAML. Vendors will be more interested in creating new >> > Eclipse tooling for XAML. .NET developers will be tempted to try RCP, >> > and they might be able to migrate some of their existing UI elements >> > as well. In short, we should always be looking at how to leverage >> > existing standards to build momentum. This is what we did by adopting >> > OSGi, and we should be looking to do the same thing in the UI space. >> > >> > But how do we address question #2? Well, saying that XAML is the story >> > we tell developers new to RCP does not mean it has to be the only >> > story. If we can back the declarative UI with an EMF model and this >> > can be made transparent to most developers, I say we do it. If this >> > makes possible competing approaches and tools for UI construction, so >> > much the better. If the model evolves into a superset of what's >> > provided by XAML, that's fine. But please let's start with the >> > mechanism that developers already understand and work back from there. >> > >> > Like the RCP user that started this thread, I'm really excited about >> > what's happening with e4 and I think it has the potential to >> > drastically increase the number of developers using this technology. >> > Keep up the great work! >> > >> > Thanks, >> > >> > --- Patrick >> > >> > >> > Patrick Paulin >> > Eclipse RCP/OSGi Trainer and Consultant >> > Modular Mind, Ltd. >> > >> > [email protected] >> > 608.213.4169 >> > www.modumind.com >> > >> > twitter.com/pjpaulin >> > linkedin.com/in/pjpaulin >> > >> > >> > >> > _______________________________________________ >> > 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 >> > > > _______________________________________________ > 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
