[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
