I'd agree with Eugene, this is definitely beginning of the end... With some difference: now eclipse is more close to the end than it was 2 years ago.
To understand this let's guess JetBrains' motivation:
]]> Please do not forget JetBrains is a small company. So a few hundred more users paid for IDE is probably nothing for IBM but a value for JetBrains. Moving to open source will very likely decrease their sales in short term because of some potential IDEA users who knows about IDEA will not buy it but will use free one. There will be some time while open-source will spread a world and reach potential users who are not aware of IDEA yet (if such people ever exists). And some of JetBrains potential users who are thinking about to buy IDEA will be OK with free version.So considering this fact let's think why they decide to move open source?
Guess #1: Their are focusing on more profitable products like ReShaper; do not count on IDEA as a profitable product and let it be open source to gain indirect benefits. If this is true, nothing positive about this move, and this is just a beginning of IDEA end.
Personally I do not believe in case #1
Guess #2: This is beginning of world-wide "JetBrains attack" on the IDE market. There is only 2 products which were restraining such an attack: eclipse and netbeans. Because while eclipse and/or netbeans are strong -- such attack would be very stupid move for (again!) small self-funded company. If guess #2 is closer to the reality, and JetBrains decided to open source IDEA -- this is a serious message to eclipse: JetBrains do not consider eclipse as a competitor in the middle term, and they believe they can take significant part of current eclipse and NB market.
Personally, I more believe in guess #2, considering stalled innovation in the eclipse ecosystem (except great things still happening at modeling); inability to explain where eclipse is moving; how it will look like in 2010 or 2012; suicide with OSGi resurrection I blogged 1.5 yrs ago, and many more things going or not going within eclipse ecosystem.
Reality of course is much more complex, but I can't see any good signal for eclipse ecosystem in relation with this event. Collaboration between two communities? Nonsense for the similar reason: JetBrains is very small. This could be possible if JetBrains will have 50% of eclipse market, which just support guess #2. And of course if they even had such plans -- they were able to make them real many times.
]]>Well, run Eclipse architecture on top of any (reasonable) modularization model including OSGi.
Do not get me wrong, OSGi is cool technology, however I do not believe OSGi is good for Eclipse. I already blogged on my vision of OSGi/Eclipse marriage, some more thoughts below:
E4 JavaScript client what to query for mime-types (Strings) supported by current Eclipse installation...
Eclipse plugin architecture serves this task well: just query for extensions bound to x.y.z.mimetype extension point. Extensions in form of DOM can be easily processed on JavaScript client, but I do not know how to implement such scenario on top of OSGi without overcomplexifying things.
Like we or not, major Eclipse Project are not on top of OSGi, and 3.x projects will not be pure OSGi projects. I mean you can not add any value to Eclipse Project using pure OSGi extensibity. To add any value you need to plug into Eclipse Plugin Registry.
So how Eclipse uses OSGi? Eclipse use OSGi for deployment... Only... Being Eclipse plugin developer for years, what I'm know about OSGi? Nothing except starting from Eclipse 3.x I need to align my plugin structure with some OSGi "stuff". In fact Eclipse continue to use Eclipse Plugin Architecture for deployment too, which has been aligned with OSGi. And we know OSGi benefit a lot from Eclipse. Did OSGi added anything to Eclipse? I guess nothing besides buzzword and possibility to say that eclipse now based on some "standard".
So is OSGi fine for E4? I do not think so. Personally I think OSGi may be seriously considered as a foundation for E4 for only 2 reasons: politics or buzzwords. Instead I'd prefer to see extended Plugin Extension Registry (more on this later), as well as ability to run Eclipse Plugin Architecture on top of any modularization model like OSGi or JSR-277.
Technically (and until we do not stuck with OSGi a lot) is much easy to run Eclipse Plugins on top of that systems instead of locking Eclipse into OSGi without any technical benefits.
Goodbye SWT...
Well, completely redesign SWT to say in line with WPF and JavaFX.
It looks like Eclipse Community completely ignore major UI trends. I posted half-dozen of posts to this blog and E4 mailing list, but this post from Ian Skerrett supported my assumption on JavaFX ignorance by key Eclipse persons. OK, I did pointed to this trends several times from technical standpint, let's look from "business" or "marketing" standpoint.
Popular oppinoin is: "Sun is too late (to RIA battle), so we will not care". I do not know who is originated such oppinion (I believe someone from Adobe), but this is simply lie targeted to people who do not want to analyze facts. Let's compare three major players (Adobe, Microsoft, Java):
Modern RIA technologies comprised of 3 important things:
All 3 things are impotant for success in RIA space, so let's look where Java stand in the past, now, and in future:
So looking at these items I can't figure why Sun is late. Probably someone can try to argue that Flash is available on 99% of browsers (all versions). OK, I do not know numbers, but let's assume at least 50% browsers have Java plugin installed. How this compare to number of Silverlight installations? Do you have Silverlight installed? OK, on the laptop I'm using to wirte this I have both IE and Firefox. For IE I have all mentioned runtimes installed, but for Firefox I have Java only. Honestly, I'm bored to install Flash plugin (for some reasons one-click-installation failed once), so I'm switching to IE sometimes for Flash content. So in terms of marketshare it's better to say Microsoft is late, Sun do not.
Developers, developers, developers. Someone may point that 99% of RIA developers are on Flex. I believe this is true number, but do you know how many Flex developers are there in the world? 0.1% of Java + .NET developers? More? 0.5%? That number does not matter. When Sun and Microsoft will finally release technologies, which are comparable to Flex, and enterprises start RIA adoption, which RIA technology do you think they will choose? That can be plain old Java vs. .NET battle in RIA space... And some other players like Adobe as usual.
OK, let's back to E4. Actually I do not care if Sun will succeed in RIA battle. What I'm care about is Eclipse as Rich Client Platform, and to be best RCP in future Eclipse need to start its shift together with MS and Sun towards better and richer UI frameworks. In terms of UI, I hope to see one of following for E4:
]]>
All that above means Eclipse Foundation built on top of 3 whales: Eclipse Plugin Architecture, SWT, and EMF. Each of these whales is vital for Eclipse Foundation existence and ambitions (in form they exists now). Let's look at each whale:
Eclipse Plugin Architecture
Eclipse Foundation did huge work transitioning plugin architecture to OSGi, influenced on OSGi, and revitalized OSGi. Let's move to the future: People expressing thank Eclipse! Eclipse did an excellent job. Now OSGi living it's own life and we have many OSGi runtime vendors. Suddenly some of Eclipse Foundation Projects, which neither use SWT nor EMF recognized that they have no connections with Eclipse Foundation. Nobody able to explain why OSGi-based financial libraries will stay at Foundation, or why OSGi-based communication protocol implementaions will stay at Eclipse Foundation. What about OR-mapping frameworks? What is the difference between Apache Foundation OSGi projects and Eclipse Foundation OSGi projects?.. [BTW Orbit will be closed] Or how Eclipse Foundation OSGi projects different to EPL-compatible OSGi projects, which are hosted at SourceForge?.. Eclipse != OSGi. Pure OSGi projects leaving Foundation... First whale (and the strongest glue) is dead...
Standard Widget Toolkit
Eclipse has strong ambitions to be a Rich Client Platform. Now Eclipse RCP is not possible without SWT. At early SWT days "SWT" was a buzzword. I saw AWT vs SWT, and SWT vs Swing articles, millions of discussions on forums and many authors rushed on IBM: "this is not pure Java", "what they're doing? this is not correct, you should respect standards", etc. SWT/Eclipse was innovating... Now SWT vs XYZ is not a hot topic. This means 1) SWT is mature 2) SWT must evolve or die. If Eclipse will loose in Desktop battle - Eclipse will not be Rich Client Platform anymore. I already mentioned that Eclipse is not involved in fight between JavaFX, WPF, and Flex. It means Eclipse will choose from winners, and if Eclipse chooses JavaFX - goodbye RCP, because OSGi + JavaFX != RCP, OSGi + JavaFX == Java, and Java is the best Rich Client Platform. All RCP-based projects leaves Eclipse World, second whale is dead.
Eclipse Modeling Framework
I'm very optimistic on the EMF future, and my scenario for 2010 is following: EMF is everywhere, and EMF and Eclipse Workbench is only one glue, which connects all Eclipse projects together: they all run in Workbench (4.0 != 2.0?) and interoperate via EMF models. Eclipse is still the best platform for modeling and tooling (Eclipse == EMF + Workbench)! Unfortunately there are no RCPs and Eclipse looks archaic (visually) similar to Motif UI in 2008 (Hi good old Rational Rose ;)).
There is no Total Eclipse more, sun shines again in Java Desktop town... A terrible scenario, isn't it?
]]>Questions:
Which programming language will be used for developing UI in e4? Consider:
In this language we shall be able to script 2D graphics instructions to support ability for end-users to develop custom components (such as Nebula controls)?
There are many talks about UI scripting in E4. If these scripts are a part of UI, which are deployed to non-Java runtime (CLR or Flash), how are you going to transpose scripts for example in Groovy to .NET or Flash environments. What other limitations will be?
If UI logic / Component, which is hosted in the webbrowser (say Flash) uses Java code heavily (from event handlers), is it supposed to call into Java over network, not allowed, or you're going to translate Java byte code into CLR/Flash and deploy it onto the client?
If everything is just fine and you managed at least (a) for Java. Why do we need to support other runtimes? (Java is already cross-platform and run within all browsers). If you disagree, and managed (a) for CLR and Flex - which Runtime will be native to E4 UI (Flex, WPF, Java)? If there is no "preferred" UI environment for E4 and E4 runs fine everywhere, what about remaining eclipse parts? Will them run headless in JVM communicating with UIs deployed to CLR, Flex, and other clients? Other options?
In relation to natural/unnatural desktop environments I'd like to share a link to GEF3D framework, which targeted to natural desktop environment as I understand it. screenshots: http://www.fernuni-hagen.de/se/personen/pilgrim/gef3d/screenshots.html and a link to screencast on the page. Do you think it will be able to develop such desktop oriented tools in E4 and expose them to the web? Will be there any limitations? [Please note Eclipse 3.x have no limitations to develop such cross-platform apps].
It looks like we are on different ends of the road, please can you go through articles of Wikipedia with a good summary of WPF and Silverlight features: http://en.wikipedia.org/wiki/Windows_Presentation_Foundation and http://en.wikipedia.org/wiki/Microsoft_Silverlight Do you have an idea how this architecture and features can be supported from E4 UI layer?
If WPF features will be fully supported in current SWT fashion, do you think it is cool to wrap all the WPF aspects in SWT? Do you think it will be cool to spell in E4 press-release "Great achievement of Eclipse Community is tremendous efforts on wrapping WPF .NET Framework in SWT... Now 80% are wrapped, innovations are continuing"? What about other .NET frameworks? Will we think about wrapping WCF to support "native" Windows Communication Layer by ECF project? What about .NET on linux? Will we wrap WPF implementations on .NET Linux? Will we switch to .NET :-) ?
]]>Actually identical look does not matter. Fact that only matter is "SWT is a redundant technology".
]]> I'm telling about L&F in terms of cross-platforming: I won't recall SWT vs. Swing discussion; I just wanted to state some facts, making me think on SWT as on redundant technology:I do not want to say we shall replace SWT with something, initially I was asking for SWT plans to understand concepts behind SWT for next say 10 years. Just like every eclipse user understanding past challenges (performance, better OS integration) and all we know the great SWT response to those challenges during past 10 years...
Regarding different approaches in UIs for web and desktop applications Jochen disagees as well: "because that strong split between browser and desktop will very likely vanish. And there is no problem in driving a Silverlight client from RAP. E4 is about offering more choice, so if you don't like "widget-based" (SWT / RAP) style web applications, you simply go and use what you like and attach it to the workbench backend."
I'd like to enforce his prediction and would like to say that split between browser and desktop already vanished. I'd like to focuse on desktop-capable runtimes and non-capable ones (I can formalize my understanding of desktop capabilities, but let's continue intuitively for now :)
I have no contras to run my desktop-oriented UI in browser with Silverlight (WPF/E), Java, or Flash VM runtimes. Moreover I would like to argue that we shall desktop-oriented applications in these (desktop-oriented) environments, but... I'm contrary to transposing my desktop application to unnatural environment (HTML + AJAX + embedded flash, WPF, applets or whatever else). I like "component-based" style of applications (actually, I do not know any alternatives to this style yet - Scene decomposition down to 2D primitives will not eliminate composition techniques).
But if we'll forget about marketing efforts, technology distribution across the world, etc and will ask ourselves as an engineers: "what is the great idea behind all that AJAX stuff?". The answer is nothing. If you remember AJAX history Internet Explorer was hacked by Google. They discovered they can query server from JavaScript using XmlHttpResponse object. Based on this knowledge Googlers added "code assistance" feature to their Search EditBox, which was excited millions and millions people around the world. That was a Great Hack, adding new capabilities to the environment (DHTML) which were not existed before. In other words they have learned how to force webbrowser to work as ANSI terminal or DOS application, just querying server and changing content appropriately [far from conceptual revolution, is not it?]. During next years all the AJAX companies employed The Great Hack to build more complex libraries, frameworks, and applications on top of it. Hell, this looks like web browsers was invented on Mars. Later Earth scientists found Alien Technology, Googlers hacked it, and millions of engineers worldwide invest all their time managing Alien Technology to behave like native Earth desktops...
Another question: Not so many years ago there was a shift from ASCII terminals to pixel-oriented grahpics. Let's imagine "standard Earth desktop" (like Java or WPF based) will be 3D or (more likely) 2D *vector* based in few years from now. Do you think people will invest more and more resources adding 3D or vector-based capabilities to unnatural environment, or finally will abandon hacks and will switch to natural ones?
I know there are many things, which forcing the world to use the Great Hack. And the Hack will be popular for a long time. RAP Technology itself is a great response to today's challenge... But why we shall support this Hack and other unnatural environments at the foundation layer (SWT)?
Another aspect I'd like to focus, is clear separation of things in web space: I'm considering Silverlight/Java/Flash as natural desktop-style environments, and HTML + AJAX as unnatural. Again in respect to DHTML UIs, I believe there will be very long life of HTML. But DHTML applications are very different and people have another requirements for that applications. For example:
And final aspect:
Flex/AIR, JavaFX, and WPF's approaches for cross-platforming (and for spreading the world) are identical: they just distribute runtime to as much platforms as possible. All three technologies are self-sufficient and they do not need anything besides runtime to run. These runtimes are: Flash VM, Java, and WPF (Silverlight = embedded versoin of WPF, initially named WPF/E).
E4 intention (as I understand it) is "super-portability" and "super-spreading": let's support all of them... and beyond (like HTML/AJAX). Is everyone here thinking this is reasonable decision? Can anyone propose a name for "support everything" programmers in addition to Ed's Teflon ones?
RAP is a great technology definitely, but take care from mind being RAPed... Please forget RAP for a minute, and think on simpe fact: each competetive technology (JavaFX, WPF, Flex) can draw on canvas in browser without a problem... Why it should not possible for SWT (to draw on canvas either in desktop or web modes)?
]]> Definitely, 2D primitives exist everywhere, so scene composed from 2D primitives can be rendered on any platform you can imagine (including your printer firmware). Rendering subsystem can also adapt rendering parameters to concrete platform capabilities (such as mobile phone, fridge screen, or high-end desktop box). For slow CPUs renderer may disable antialiasing, choose faster algorithms with worse result, replace gradient fills with solid fills, discard opacity, etc. Such adaptation can be very dynamic, depending on your *current* CPU load. If we'll have EMF (or something else)-based UI model in memory - we do not bother with any "UI thread" issues, flickering, etc - Rendering thread is just repainting our UI scene as fast as it can (showing FPS counter in top-right corner :))... So if your button floating off the screen very fast (with some animation effect) and on slow CPU - that's OK, end-user will just miss effect but will not wait hundreeds of repaintings until message queue fully processed. OK, I'll stop for this moment, since the time that I started to think more about all this stuff things become more interesting.OK, point #1: If I understand SWT main goal right, SWT's main purpose is to run fast enough on supported platforms (comparing to Swing). After 9 years (I do not know exact SWT age) we have no such problems. Canvas is much portable and fast enough.
So we'll have almost the same look-and-feel on all platforms (depending on their capabilities in terms of canvas size, color schemes, input devices, and computing resources available). This approach looks to be more visually cross-platform comparing to SWT (just run Eclipse on Motif to ensure). Technically, SWT runs on all platforms where Java exists. Canvas is the same - you may find it everywhere.
As for web, of course you can expose such 2D-based UIs with web-brower using Java, SVG, Flash, WPF/E, and other capable runtimes (I mean runtimes which can render 2D graphics fast)... But I think you are wondering about exposing this UIs to non-capable runtime, such as HTML document (assuming there are no capable runtimes embedded). The answer is clearly NO. From my perspective exposing something like SWT GUI to AJAX can not be named "cross-platform". This is something I'd like to name "trans-platform".
Folks, let's look from another perspective: projects, which try to expose traditional desktop UIs to the Web exist since Web became popular (90yy). I remember that there was 4-letter acronym Apache project targeted to this goal, tens of projects from universities, and works of hobbyists exposing AWT controls as HTML forms. I remember demos of UI forms developed in early Delphi 2.0 and exposed to the web, etc. They all did not succeed (is anyone know popular website developed with such technology before AJAX?).
With XMLHttpRequest flaw discovery and after AJAX invented it's possible to expose desktop UIs to the Web better. For example CodeGear implemented VCL (which is BTW the best UI library I saw in 90yy) with AJAX, and developed "Delphi for PHP". After product unveiled, I suppose there was a lot of smiles on engineers' faces regarding such strange mix of technologies. Do you know any website developed in "Dephi for PHP"? Or have you even heard about this product? So you can understand how popular it is. But... "Delphi for PHP" is conceptually identical to Eclipse RAP. Technically I'm impressed with Eclipse RAP. RAP did a tremendous and *valuable* job in that domain. A great value of RAP that I can expose existing RCP apps to the web very fast. That's exciting...
However, I will not choose neither "Delphi for PHP" nor Eclipse RAP for my new project. The reason is simple: "I do not want my application to behave similar on the web and on the desktop. I remember all those universal UI projects telling: "we'll render your UI to environment of any type". My answer is: "please do not render my UI to any environment"... cause they're too different. And I love my UI look-and-feel, and I want the natural fit of my UI into target environment.
Starting with interface design I have different goals in mind. Some basic things: I will fit my UI on the desktop (which is limited area, so I'm layouting application appropriately). To the contrary I want to see my web-based application to look more like printed document - I do not want to see scrollbars everywhere and other stuff like that. I will use screen flow (perspective switch extensively). When I open a browser I have no the intention to spend hours in editor view, but to surf though my data and information with a comfort. I believe (but I have not tried yet :)) if you ask experienced UI designer to develop and interface for your web-based app (say bug-tracker) and ask another one to design UI for your desktop bug-tracker - you'll see very different results.
There is nothing about technical possibilities and limitations, it's all about how people feel and sense different enviroments (either web, desktop and mobile). Personally I think unified, trans-platform UI frameworks is just a misidentification. I do not talk about MDA, there are a lot of senses transforming UI models to implementations, which are relevant to target environments, but there is no sense in developing my UI logics on top of unified interface (SWT+).
OK, point #2: Great engineers built Eclipse, it's comparable to art to see tens of layers within eclipse, how they're communicate, and how I can plug into any layer and expose new higher-level functionality to the outer world. It's really about software genesis (I can't say development, as eclipse is more than development). When it comes to UI, as Eclipse consumer I'd like to see the same picture - correct abstractions and well-designed layers. SWT is true cross-platform (it supports all the OSes where Java runs). SWT + RAP approach is to make it trans-platform. That's defenitely sounds cool, but I'm afraid it may be misidentificated target.
]]>So regarding buzz - I do not think this is a buzz, but natural evolution of UI started with SVG and Flash; higher-level technologies like Flex; and continued with JavaFX/WPF. It is constantly running evolution during last years, and finally we have these technologies ready for end-users, and end-users have PCs powerful enough to run such UIs. So there is a trend to decomposite UI down to 2D (3D? :)) primitives. And such decomposition rules will be fully controled/defined by application, which is contrary to original SWT idea and goal.
]]>I strongly believe in importance and benefits which we can get from both declarative UIs and scripting and our company have some experience in this field (yep, we lead Eclipse DLTK:), which I would like to expose briefly before to continue.
]]> Contrary to thoughts of many Eclipsers (based on Eclipse Monkey experience) ability to develop Eclipse-based products completely in sciprting languages exists since 3.1 - for few years, since IExecutableExtensionFactory was introduced.Technique is simple like this:
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin>
<extension
point="org.eclipse.ui.views">
<category
id="category.helloworld"
name="Scripting Demo"/>
<view
category="category.helloworld"
class="org...JavaScriptExtension:/scripts/helloworld.js"
id="view.helloworld"
name="HelloWorld View"/>
</extension>
</plugin> JavaScriptExtension (implements IExecutableExtensionFactory) retrieves script from location specified in extension data, execute script and returns script result (of course it shall be of type required by corresponding extension point). Technically you can implement any Java interface and derive from Java class using any JVM scripting language, so since Eclipse 3.1 there are no obstacles to develop plugins without any line of Java code ("biggest" problem is classloading issues :).
In 2005 we started a project named RCPML, which is about to develop Eclipse-based application completely in scripting languages. Besides scripting part project introduced declaraive UIs, CSS support, etc.
From end-user perspective UI definition in XML-based declarative language looks like:
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin>
<extension
point="org.eclipse.ui.views">
<category
id="category.helloworld"
name="Scripting Demo"/>
<view
category="category.helloworld"
class="org.rcpml...RCPMLExtension:/views/helloworld.xml"
id="view.helloworld"
name="HelloWorld View"/>
</extension>
</plugin>
And View code itself:
<?xml version="1.0"?>
<ui:view xmlns="http://rcpml.org/swt"
xmlns:ui="http://rcpml.org/ui">
<label>Hello World</label>
</ui:view>
...where xmlns="http://rcpml.org/swt" is a package (in terms of EMF) with components reflecting SWT world, xmlns:ui="http://rcpml.org/ui" package reflect Workbench classes, etc.
We instantiate DOM from the file specified. Package-aware "renderers" maps DOM objects to corresponding problem-domain objects (SWT, etc), install appropriate listeners and translate SWT UI events to DOM events, listening for DOM changes and update views (in terms of MVC), as well as scripts (JavaScript) are triggered by DOM events and executed against DOM instances.
Besides this we support both CSS for layouting and components styling: please look at "classical" Eclipse forms tutorial "ported" to RCPML:
CSS for layouting example:
<ui:view xmlns="http://rcpml.org/forms" xmlns:ui="http://rcpml.org/ui" xmlns:core="http://rcpml.org/core">
<core:style type="text/css">
form#myform {rcpml-layout:grid;rcpml-layout-columns:2;}
form#myform > hyperlink {rcpml-colspan:2}
form#myform > text {rcpml-fill:horizontal;rcpml-grab:horizontal;}
form#myform > checkbox { rcpml-colspan:2; }
</core:style>
<form id="myform" title="This is RCPML Form">
<hyperlink>Click here</hyperlink>
<label onclick="javascript: this.color=#ff0000">Text field label:</label>
<text/>
<checkbox title="An example of a checkbox in a form"/>
</form>
</ui:view>
This RCPML stuff exists for years. Initially done as a proof-of-concept, it was used in several products including commerical ones having thousands of users. For example Zend Studio for Eclipse uses RCPML-based properties view and dialogs. If it's interesting for you see RCPML-based UI in action at second part of this screencast... so I'm a little bit aware of the problems and ideas related to modeled UI and scripting.
Is this important for E4?
Definitely both declarative UI and scripting could be a huge benefit for Eclipse, and according to my current expertise I'd vote for EMF to be used for UI modeling instead of DOM... however many things shall be worked out. W3C have everything necessarily for years: DOM event model, JavaScript bindings, CSS formalized, etc...
I appreciate this discussion and direction very much, but having that RCPML stuff done (and as I mentioned, ability to script your plugins without a line of Java code already exists), I do not think that this is a good direction for E4: there is no conceptual changes, and both declarative UI/scripting can be introduced in Eclipse 3.5 (including fully scriptable workbench with mininal API changes).
If E4 is going to be true next-generation, we need a
Conceptual shift for UI paradigm...
As for me, this shift must be from underlying OS widgets-based approach (SWT-style) to UI decomposition down to 2D (3D) primitives and rendering to canvas (as we see in WPF). Conceptually JavaFX and WPF are about high-performance UI models transformations and rendering. JavaFX Script is a cool language for dynamic UI model manipulations. JavaFX render to DirectX/OpenGL. WPF render to DirectX. Past time Sun improving Java Runtime to support JavaFX well, Microsoft adding new features to DirectX like glyphs caching to support WPF. JavaFX and WPF UI models decompose down to rendering primitives such as lines, brushes, and fills. Everything they need is a canvas, and their performance is just impressive. (Intersing that rendering to canvas will break all the borders between SWT and GEF). Modern UI layer must be able to render UI models to canvas, and SWT looks redundant with its dependency on underlying platform components.
I'm very happy to see modelled UI discussion at E4 list, and I'm agree with most points there. But did anyone ask a simple question: "how E4 will render button, or text-edit control"? And corresponding question: "what is a physical button from E4 standpoint"... It seems like everyone silently assume that SWT will handle this... From my side, if E4 will physically treat button as underlying OS widget (e.g. GTK) - I'd prefer to consider JavaFX for my non-tooling projects (and who knows how many people will switch to Netbeans later)...
I hope discussion on new concepts will be raised soon...
For me eclipse is everything during past 5 years: my work, my hobby, my hopes... I can find everything I need among Eclipse technologies. If I can't find anything I can develop it. After looked at JavaFX/WPF - I can't imaging anything better, but I can't have such technologies in my eclipse-oriented world. Most disappointing to my totally eclipsed mind that I can have them now, but out of eclipse. In 2008 I can start programming with WPF/JavaFX and provide UI designer with top-notch tooling. While E4 is just an incubation community-driven project at warming up stage, well funded and formed teams at Sun and Microsoft worked hard on new UI development concepts for past years. They done, E4 did not started.
Folks, we talking about to run E4 on desktop OSes and to support web runtimes such as Flash, they own that runtimes (Java and WPF/Silverlight); we talking about new programming models for UI; they own new technologies introducing new programming concepts for UI (JavaFX Script and WPF/XAML) and these programming models doing a lot intersting things in terms of databinding, event processing, UI composition, rendering, and performance optimizations - E4 did not face that problems in practice yet. We predict to have something (hope "something" will include great UI tooling) in 2010 - Sun and Microsoft releasing tools for their technologies in 2008. Microsoft already shipping Microsoft Expression WPF tooling and we're awaiting JavaFX design tools, which will be interoperable with Adobe products this year.
I did shared my concerns with a friend (who is an eclipse committer). I told, hey I'm frustrating how eclipse is far from what I saw in WPF and JavaFX. The answer was: It's OK - Eclipse is a conservative platform... This is contrary to my understanding of Eclipse during past years - I was thinking Eclipse is an innovative platform.....
5 years ago SWT was a best choise for me: it was much rich compating to AWT and much faster comparing to early Swing. Now SWT looks like dinosaur comparing to WPF and JavaFX. Do you think it's possible to jump into this running train? Will be there a switch to JavaFX? For now it looks like Eclipse do not even bother to catch it. If there will be no switch to JavaFX, can Eclipse Foundation commit enough resources to develop alternative but comparable technology (SWT+? RAP 2.0?) and relevant tooling?