[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse-incubator-e4-dev] More on XAML was: [E4 probably toolate?]
|
>It's very intersting to understand your approaches to other problems
besides format used to read models.
How about GUI extensibility?
Best regards
Yves YANG
-----Original Message-----
From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
[mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On Behalf Of Yves YANG
Sent: Monday, April 14, 2008 2:01 AM
To: 'E4 developer list'
Subject: RE: [eclipse-incubator-e4-dev] More on XAML was: [E4 probably
toolate?]
Hi Andrey,
XAML's intention is to provide a common UI support to meet the requirements
of different users:
1. Component developers
Who know all detail of XAML/WPF to implement reusable UI
components. The tool they need is the XAMLPad (= XML editor).
2. Domain developers
Who take care of the simple and abstract level of domain
components provided by Component developers. They can ignore all advanced
and technology stuffs. Mainly they need a visual editor like VE.
We have worked on this project:
http://www.eclipsecon.org/2008/index.php?page=sub/&id=31
3. Architects
Who focus on system design. They need a modeling solution with
MDA approach to generate UI. They use the components in modeling environment
provided by Domain developers.
Here is the demo I made during EclipseCon 2008 to show the UI MDA
concept:
http://www.soyatec.com/eface/webdemo/#PMF
4. Graphic designer
Who deal with the visual presentation. They need the high level
visual edition tools like "Expression Blend".
Can JavaFX cover of these requirements?
>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
It is a good issue. In general, we should deal with two areas:
1. Resource loading
In XAML/WPF, the XML file is compiled in binary format: BAML. It
improves the file loading. ED said EMF has implemented the similar features.
JFI, eFace has not implemented it since we think it is not so critical.
2. Event handling
It is the most important issue in terms of turning. The event
notification must be handled at Property level. We should enable to register
a listener on a property, instead of object. You are right maybe EMF has a
limitation on this matter.
> 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?
We haven't implemented the storyboards. But we go further: we have
implemented the Data Template. The Data event notification is mush complex
than Control event notification.
> 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?
We didn't perform the benchmark. We have spent a lot of time to turn the
Data presentation. The graphic animation is not our priority.
>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.
Do you think the script language like JavaFX is suitable for DSL modeling?
I believe the XML markup is good solution. Probably, EMF is a good candidate
although there are several issues to investigate.
The script can be used for event handling. I definitively disagree with the
UI structure description in scripting language since it targets to
programmers and reverse/forward UI edition by tools is very difficult.
Best regards
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: Monday, April 14, 2008 12:55 AM
To: E4 developer list
Subject: [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
_______________________________________________
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
