[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-incubator-e4-dev] E4 probably too late?
|
Hi Jochen,
Thank you for sharing thoughts, and please do not consider me as SWT or RAP antagonist. As an eclipse consumer I would be happy to see eclipse as a set of self-sufficient technologies in every space I use for years...
a) Actually identical look does not matter. I'm telling about L&F in terms of cross-platforming: it's harder to look identical of you do not control all the aspects of rendering (e.g. delegate some parts of the process to outer world like SWT does to underlying OS UI layer). I won't recall SWT vs. Swing discussion; I just wanted to state some facts:
- It's easier to stay cross-platform with 2D-approach: this approach supported on all the platforms where Java runs with zero efforts.
- There are no performance issues anymore. Now it's hard to argue why we need SWT from performance perspective.
- Native OS components are deprecating. WPF already render .NET objects to DirectX canvas. At which layer of "supported" enviroments will SWT map (or render). Which layer of "supported" environment custom SWT components will use for rendering 2D primitives? Do you have an example how custom SWT component will be rendered to WPF and to AJAX? If WPF styling/templating if going to be supported, how do you going to support cross-platform look and feel (e.g. same look on Linux/GTK for WPF-styled component)?
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...
b) I'd like to enforce your prediction and would like to say that split between browser and desktop already vanished. In (b) I was telling about 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 Silverlight (WPF/E), Java, or Flash VM client. 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:
- To be search engine friendly, and REST-styled to identify piece of information, for cross-linking, etc
- Information-oriented layouting I mentioned before.
- I guess many more...
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?
> I would be very much interested in the innovative concepts that are in JavaFX / WPF that you think can not be well addressed with e4.
Bad thing is I can't answer your question because I can't imagine how "widget-based" SWT/RAP style applications can "support" WPF features at all. I understand that JavaFX alternative can be built in Java (or other language), which will run within JRE and use OpenGL or use Sun's Graphics2D as display. I understand that alternative to WPF (which is actually .NET framework rendering to DirectX) can be build in Java (or another language), which will run within JRE and use OpenGL or use Sun's Graphics2D as display :). But I'm getting lost when thinking how to transpose "universal" E4 UI to any of runtime.
Technically WPF UI is CLR code + XAML data; Silverlight UI is same (CLR + XAML + optionally DLR); JavaFX Script compiles to Java byte code...
So, to be able to run on WPF and Java and Flex as designed, e4 UI shall be able to translate itself into target runtime code (CLR, Java, Flash respectively), similar to OpenLaszlo compilation of LZX/JavaScript into Flash and/or DHTML/JavaScript), or Google GWT (which compiles Java into DHTML/JavaScript). If I'm correct with e4 goals, then
a) Which programming language will be used to program UI in e4? Consider:
1) We shall be able to compile this language into CLR instructions + XAML, Java bytecode, and Flash programs.
2) To support target environemtns fully, this language shall be as much expressive as JavaFX Script, XAML, or Flex.
3) To provide same set of the components (and to have SWT-alike custom components on all supported environments) we shall develop Basic set of reusable components (widgets) in this language.
4) 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).
b) There are many talks about UI scripting in E4. If this scripts will be a part of UI, which shall be 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?
c) 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?
d) 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?
e) In relation to natural/unnatural desktop environments I'd like to share a link to application, which targeted to natural desktop environment as I understand it: http://www.fernuni-hagen.de/se/personen/pilgrim/gef3d/index.html 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 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% is wrapped, innovations to be continued"? What about other .NET frameworks? Shall we think about to wrap WCF to support "native" Windows Communication Layer by ECF project? What about .NET on linux? Shall we wrap WPF implementations on .NET Linux? Shall we switch to .NET :)?
Sorry for stream of questions, and please feel free to ignore any of them (most are just rhetorical stuff).
Thank you, and
Kind Regards,
Andrey
----- Original Message -----
From: "Jochen Krause" <jkrause@xxxxxxxxxxxxxx>
To: "E4 developer list" <eclipse-incubator-e4-dev@xxxxxxxxxxx>
Sent: Tuesday, April 15, 2008 11:42:31 PM GMT +06:00 Almaty, Novosibirsk
Subject: RE: [eclipse-incubator-e4-dev] E4 probably too late?
Hi Andrey,
Thanks for caring, taking time and effort to post to this group.
If I understand you correctly, you want
a) Same L&F für SWT for all platforms by leaving native widgets behind
b) For the web you like something radically different
With respect to a) I disagree. In essence that is the Swing vs. SWT discussion again, and this has been discussed for ages. There is more to this discussion than performance. I agree that SWT needs more *sexy* animations, but this can be (and is being) adressed without moving away from native widgets. New platforms like WPF and AIR offer new capabilities that we can take advantage of.
Also for b) I disagree, 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 would be very much interested in the innovative concepts that are in JavaFX / WPF that you think can not be well addressed with e4.
Cheers,
Jochen
------------------------------------------------------------------------------
Jochen Krause
Tel: +49-721-664733-0
http://innoopract.com
-----Original Message-----
From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx [mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On Behalf Of Andrey Platov
Sent: Tuesday, April 15, 2008 5:56 PM
To: E4 developer list
Subject: Re: [eclipse-incubator-e4-dev] E4 probably too late?
Hi Tom,
I think it's easier to stay cross-platform with canvas-based approach comparing to widgets-based approach.
1) 2D primitives exists everywhere, so scene composed from 2D primitives can be rendered on any platform you can imagine (including printer firmware). Also rendering subsystem can adapt rendering parameters for 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. Also 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 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 now, since more I think about all this stuff more intersting things comes.
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 same_ look-and-feel on all the platforms (depending on their capabilities in terms of canvas size, color schemes, input devices, and computing resources available). This 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.
2) 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 to expose 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 shall 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 exists since Web became popular (90yy). I remember there was 4-letter acronym Apache project targeted to this goal, tens of projects from univerities, 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 much better. For example CodeGear implemented VCL (which is BTW the best UI library I saw in 90yy) with AJAX, and developed "Delphi for PHP" (http://www.codegear.com/products/delphi/php). After product unveiled, I believe 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 did you even hear 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 tremendous and *valuable* job in that space. And 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 look and 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 natural fit of my UI into target environment.
Starting from interface design I have different goals in mind. Some basic things: I shall fit my UI on the desktop (which is limited area, so I'm layoting application appropriately). Opposite I want 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'm opening browser I have no intention to spend hours in editor view, but to surf though my data and information with a comfort. I believe (but did not tried yet :)) if you'll 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 possilities 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 sense transforming UI models to implementations, which are relevant to target environments, but 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 outer world. It's really about software genesis (I can't say development, eclipse is more than development). When it comes to UI, as Eclipse consumer I'd love 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.
Thank you, and thanks for the link. That ribbon control looks extremely attractive.
Andrey
----- Original Message -----
From: "Tom Schindl" <tom.schindl@xxxxxxxxxxxxxxx>
To: "E4 developer list" <eclipse-incubator-e4-dev@xxxxxxxxxxx>
Sent: Tuesday, April 15, 2008 7:06:53 PM GMT +06:00 Almaty, Novosibirsk
Subject: Re: [eclipse-incubator-e4-dev] E4 probably too late?
Andrey Platov schrieb:
> Hi Ed,
>
> As for Jim van Dam's approach, I'd agree - it is not only compelling,
> it's natural aproach to UI development and similar to JavaFX/UI. The
> devil in the details: how we will transform higher level UI
> abstractrions into final representation. Atomic block in "old UI"
> composition is a widget. Atomic block in JavaFX/WPF is a 2D graphics
> primitive. These technologies treat Classical Widget as a composite of
> lower-level primitives, and these primitives available on every
> platform (which is not true for Widget-based approach) - just to
> support Jim van Dam's run everywhere point. This is not conceptual
> shift, but
>
> 1) few years ago we were not able to develop such UIs due to CPU/GPU performance limitations (and this was main reason why SWT was born).
Well so you suggest that SWT is going away from native widgets drawing everything on the GC? I agree with you that there are amazing things one can do. Seeing controls like [1] are amazing but the problem I see is how to make them cross-platform (e.g. draw them in browser).
Tom
[1]http://www.hexapixel.com/ribbon/
--
B e s t S o l u t i o n . a t EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl leiter softwareentwicklung/CSO
------------------------------------------------------------------------
eduard-bodem-gasse 8/3 A-6020 innsbruck phone ++43 512 935834
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
