[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[eclipse-incubator-e4-dev] More on XAML was: [E4 probably too late?]
|
Hi Yves,
Regarding JavaFX vs WPF:
I believe Microsoft never intend XAML to be human-readable (and of course human-editable) language. As a person who is working on XAML-related solution you'd probably find it hard to read it.
XAML is like SVG - not for manual authoring. JavaFX script is much better for human - it was initially designed with human-readability in mind. However to utilize both technologies you'd need graphical tooling like Microsoft Expression or Adobe set of designer-oriented tools (and Sun is heavily working on them). Both WPF and JavaFX designed to involve UI designers active in software development process - they do not expect UI will be *typed* in XAML. UI will be designed with graphical tools (please look at screenshots from my earlier post: http://dev.eclipse.org/mhonarc/lists/eclipse-incubator-e4-dev/msg00175.html); UI logic will be added later to the design (pretty much as in Web development).
BTW XAML for example in that post looks like:
<TextBox RenderTransformOrigin="0.5,0.5" d:LayoutOverrides="Height" HorizontalAlignment="Right" Margin="0,0,98.315,191.538" VerticalAlignment="Bottom" Width="211.3" Text="TextBox" TextWrapping="Wrap" FontFamily="Showcard Gothic" FontSize="18">
<TextBox.RenderTransform>
<TransformGroup>
<ScaleTransform ScaleX="1" ScaleY="1"/>
<SkewTransform AngleX="38" AngleY="0"/>
<RotateTransform Angle="-31.289"/>
<TranslateTransform X="0" Y="0"/>
</TransformGroup>
</TextBox.RenderTransform>
</TextBox>
Do you think there are many engineers who can imagine rendered XAML representation after all transformations applied to stack of components, or there are persons who able to understand look of this figure?:
<Path HorizontalAlignment="Left" Margin="48,0,0,118.118" VerticalAlignment="Bottom" Width="130.5" Height="35.882" Fill="#FFFFFFFF" Stretch="Fill" Stroke="#FF000000" Data="M48,290 C133,345 177.5,318.5 177.5,318.5"/>
Again standard XML tools are useless for XAML like they're useless for SVG. JavaFX Script is more human-oriented but this is not eliminate need of good tooling.
In fact declarative is not always human readable. Declarative is about programming paradigm.
According to your post I'm afraid you did focused on wrong aspects of WPF and JavaFX. You're talking about languages, which is definitely not a problem for E4 (especially Eclipse is a best tooling to support any language). There are another challenges in work on WPF/JavaFX alternative:
Computing model: Both WPF and JavaFX have several intersting things like:
Attributes binding (JavaFX script):
class HelloWorldModel {
attribute saying: String;
}
var model = HelloWorldModel {
saying: "Hello World"
};
Frame {
title: "Hello World JavaFX"
width: 200
content: Label {
text: bind model.saying
}
visible: true
};
Here label's text value will be in sync with model. Or more interesting example:
class Cutout extends ImageView {
attribute x: Number;
attribute y: Number;
attribute url: String;
attribute movable: Boolean;
}
attribute Cutout.movable = true;
attribute Cutout.image = Image { url: bind url };
attribute Cutout.transform = bind translate(x,y);
Here on x or y attribute change, transform attribute will be updated with results of translate function call.
Looks easy to implement with EMF, but challenges are
1) performance: these binding (and triggers, and animations - another aspects of their computing model which I did not included in post) are vital to JavaFX/WPF components. Amount of (re)calculations can be very huge for practicular scene, so EMF notifications do not look to be fast enough solution
Regarding to eFace/XAML it's very interesting to know how you implemented triggers (for example how do you map SWT events to XAML model), how you working with storyboards, and stuff like that?
2) Syntax - shall we use DSL to declare UIs (JavaFX approach) or serialized EMF models (WPF) approach? Anyway I think powerful tooling required for both.
Runtime Library:
If you working with XAML, you know what Button in WPF Aero is. I'm extracting part of template:
...
<LinearGradientBrush x:Key="ButtonNormalBackground" EndPoint="0,1" StartPoint="0,0">
<GradientStop Color="#F3F3F3" Offset="0"/>
<GradientStop Color="#EBEBEB" Offset="0.5"/>
<GradientStop Color="#DDDDDD" Offset="0.5"/>
<GradientStop Color="#CDCDCD" Offset="1"/>
</LinearGradientBrush>
<SolidColorBrush x:Key="ButtonNormalBorder" Color="#FF707070"/>
...
Button is one of simplest things - it's just a rectangle, gradient fills, etc. Other controls are much complex (such as trees, and tables). Amount of work on WPF/JavaFX-alike runtime library looks to be huge...
Rendering Performance:
Rendering performance is another big challenge, we shall optimize scene and respond to model changes very fast. Unfortunatley there are no good UI performance tests, but there is bubblemark effort: http://bubblemark.com/. As I know from blogs, both WPF and JavaFX now 200 FPS on bubblemark, Flex is 50-60 FPS. Did you tried to implement bubblemark test (or something like that) with eFace to count your performance on SWT?
It's very intersting to understand your approaches to other problems besides format used to read models.
Regarding "XML GUI for Java". If we'll remove XML word from your topic, the topic will be "UI for Java". So the answer depends on our understanding of UI for Java. If our understanding that UI for Java is a union of all available models like Swing and SWT - we shall have common model, which is able to map to each of supported models. This is "super-SWT" approach (actually SWT is what you call "standard" for underlying OS UI models supported by SWT)... If we think that UI for Java is "anything" we know how to render on Java-enabled device and able to provide feedback from device - we do not need "standard". This is WPF/JavaFX approach, and big conceptual difference:
JavaFX/WPF do not delegate anything to outer world, moreover JavaFX do not delegate rendering to application at all (such as Canvas.drawLine...). Application and runtime responsible to decompose UI down to primitive UI elements, but rendering is a subject of framework. That's really impressive :)
Thank you very much,
Andrey
----- Original Message -----
From: "Yves YANG" <yves.yang@xxxxxxxxxxx>
To: "E4 developer list" <eclipse-incubator-e4-dev@xxxxxxxxxxx>
Sent: Sunday, April 13, 2008 7:04:35 PM GMT +06:00 Almaty, Novosibirsk
Subject: RE: [eclipse-incubator-e4-dev] E4 probably too late?
Script programming (JavaFX) vs XML programming (XAML/WPF)
---------------------------------------------------------
Form user's perspective, the Script programming like JavaFX still addresses
programmer as Java. Building the UI tools for it isn't straightforward.
However, XML programming relies on a modeling behind such as XML schema, EMF
or others. An UI structure can be read and transformed to others very
easily. The integration with standard XML tools is petty easy. And building
of the tools for business analyst becomes possible.
XML GUI for Java
----------------
In Java, there is a huge list of UI technologies such as Swing, SWT, JSF,
etc. Each has a different UI model. A standard UI model equivalent to WPF is
missing. The question is if we have to invent a new common UI model or just
to define a specific UI model for SWT?
Yves YANG
http://www.soyatec.com
-----Original Message-----
From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
[mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On Behalf Of Andrey
Platov
Sent: Sunday, April 13, 2008 1:32 PM
To: E4 developer list
Subject: Re: [eclipse-incubator-e4-dev] E4 probably too late?
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).
2) now scaling down to lower-level primitives gives new very attractive
possibilities like: run everywhere (if something can provide adequate
CPU/GPU power and runtime), clean separation of UI represenation and UI
logic (we may expect designers working on desktop designs in near future
like we see in Web design market), flexible UI customization at run time and
at any level (in WPF I can override Button look-and-feel for example adding
rotate and scale transorm, adding few lines around caption, etc... I can
completely replace look-and-feel of my button at application or window level
- and all these will be vector graphics - just forget about pixels)! This is
also very attractive from UI components reusing and representation
inheritance standpoints, etc. Of course there are much more benefits we can
figure out...
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 past
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
shall be fully controled/defined by application, which is contrary to
original SWT idea and goal.
Sincerely,
Andrey
----- Original Message -----
From: "Ed Merks" <merks@xxxxxxxxxx>
To: "E4 developer list" <eclipse-incubator-e4-dev@xxxxxxxxxxx>
Cc: "eclipse-incubator-e4-dev" <eclipse-incubator-e4-dev@xxxxxxxxxxx>,
eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
Sent: Sunday, April 13, 2008 8:23:05 AM GMT +06:00 Almaty, Novosibirsk
Subject: Re: [eclipse-incubator-e4-dev] E4 probably too late?
Andrey,
Are you sure "FX" isn't just the latest buzzword designed to appeal to the
Teflon Programmers of the world?
http://ed-merks.blogspot.com/2008/04/teflon-programming.html
It seems to me there's yet another cool way to build UIs approximately
every other week. I suppose we can only hope that eventually someone will
do something of lasting value, but what makes you believe this would be it?
Until then, I'll personally remain skeptical of anything that smacks of
hype and place my bets on technology that's focused on lasting value...
When it comes to innovative ideas, I found Jim van Dam's approach to
Intentional UI modeling to be quite compelling:
http://www.eclipsecon.org/2008/index.php?page=sub/&id=56
But of course for me, everything is about modeling. The realization of
those models, along with the details about how to render them in the
shifting UI technology stack, seems subservient to the high level
abstractions that transcend these details...
Without something of lasting value, we'll all remain in the "rinse, lather,
repeat" loop for our entire careers...
Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 313)
Andrey Platov
<andrey@xxxxxxxxx
> To
Sent by: eclipse-incubator-e4-dev
eclipse-incubator <eclipse-incubator-e4-dev@eclipse.o
-e4-dev-bounces@e rg>
clipse.org cc
Subject
04/12/2008 07:41 [eclipse-incubator-e4-dev] E4
PM probably too late?
Please respond to
E4 developer list
<eclipse-incubato
r-e4-dev@eclipse.
org>
Hi folks,
Few weeks passed after EclipseCon but I'm still under E4 impression. I saw
excited people around applauding demos of scripts, which changes caption
color. I saw full room of people excited with demo of the editor on the
web, and I believe many of them left EclipseCon feeling bright Eclipse
future. I have heard from E4 gang "we do not know details but it will be
cool", and I believe E4 will be cool. There was questions about 3.5,
diversity, and technical problems (like event handing), but to the best of
my knowledge no one asked E4 gang: "guys, why do you so happy? do not you
think E4 is very late?.. probably too late".
As for me - I left EclipseCon with dark thoughts about Eclipse future.
There are two names made me unhappy: WPF and JavaFX. Nevertheless I'm aware
of WPF and JavaFX exists I did not paid attention to them. After I looked I
was shocked. Both WPF and JavaFX very similay and both are definitely new
way to develop UIs. And SWT (as well as "classic" component based OS UIs)
is far away. I'm afraid many eclipse developers did not looked into WPF or
JavaFX deep. Personally I was thinking about them like declarative UI
languages and corresponding frameworks - nothing new comparing to
DHTML/Scripting for example. But I was totally wrong - they definitely
rethinked how UIs shall be build. After looking inside I started trust
Sun/MS marketing people and believe that any of these two technologies can
start new age for UI development.
For me eclipse is everything during past 5 years, my work, my hobby, my
hopes... I can find everything I need in eclipse world. 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 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 (upcoming
JavaFX design tools, which will be interoperable with Adobe products, and
Microsoft Expression WPF tooling).
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?
Please can anyone comment of my concerns about SWT future (I mean basic UI
rendering layer for E4).
Will be there a switch to JavaFX? If not - do you think there can be enough
resources involved to catch JavaFX/WPF with alternative but comparable
technology (New SWT) and relevant tooling?
Kind Regards,
Andrey Platov
Eclipse DLTK Project Lead
_______________________________________________
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
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
