XAML/WPF hasn’t any
layout at all. It provides four kinds of panel instead.
- StackPanel
A panel has a layout same as FillLayout in SWT
There is a vertical column:
<StackPanel Orientation=”Vertical”>
<Button Content=”Button1”/ >
<Button Content=”Button2”/ >
<Button Content=”Button3”/ >
</StackPanel>
- DockPanel
A panel has a layout same as FormLayout in SWT
An example to manger form attachment:
<DockPanel>
<Button DockPanel.Dock=”Top” Content=”Button1”
/ >
<Button DockPanel.Dock=”Top” Content=”Button2”/
>
<Button DockPanel.Dock=”Top” Content=”Button3”/
>
</DockPanel>
There is an “attached property” concept used in the children
of the container. The Dock property is defined in the container DockPanel, but
this property is not used in the container, but in its children.
The button1’s top edge is attached the container,
The button2’s top edge is attached to the “Button1”’s
bottom
The button3’s top edge is attached to the “Button2”’s
bottom and its bottom is attached to the container’s bottom.
- Grid
A panel has a layout same as GridLayout in SWT
<Grid>
<Grid.RowDefinitions>
<RowDefinition/>
<RowDefinition/>
<RowDefinition/>
</Grid.RowDefinitions>
<Grid.ColumnDefinitions>
<ColumnDefinition
/>
</Grid.ColumnDefinitions>
<Button Grid.Row=”0” Grid.Column=”0”
Content=”Button1” / >
<Button Grid.Row=”1” Grid.Column=”0”
Content=”Button2”/ >
<Button Grid.Row=”2” Grid.Column=”0”
Content=”Button3”/ >
</DockPanel>
The “Row” and “Column” are the attached
properties of Grid. This example defines three rows and one column.
- Canvas
A panel has null layout.
<Canvas>
<Button Canvas.Left=”10” Canvas.Top =”10”
Content=”Button1” / >
<Button Canvas.Left=”10” Canvas.Top =”40”
Content=”Button2”/ >
<Button Canvas.Left=”10” Canvas.Top =”80”
Content=”Button3”/ >
</Canvas>
The “Left” and “Top” are the attached
properties of Canvas. They correspond to the location x and y.
My feeling is these
layouts are very simple and can be used directly by non-software engineers in a
XML editor or a Visual editor.
XAML Style relies on the
default value resolution. A WPF object is a dynamic object. Each object has a dictionary
of properties. When we call getValue() method and there is no such entry in the
dictionary, the default value resolution is activated. One of the possibilities
is to find the value in the Style definition through its parent tree.
<Canvas>
<Canvas.Resources>
<Style TargetType="Label">
<Setter
Property="FontSize" Value="16" />
<Setter
Property="FontWeight" Value="Bold" />
</Style>
</Canvas.Resources>
<Label
Text=”Styled Label”/>
</Canvas >
This code has the same
result as following:
<Canvas>
<Label
FontSize=”16” FontWeight=”Bold” Text=”Styled Label” />
</Canvas >
I believe that the
support of CSS can be done straightforward.
Please feel free to ask
me any questions about XAML.
Yves
From:
eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
[mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On Behalf Of Kevin McGuire
Sent: Friday, April 04, 2008 9:57
PM
To: E4 developer list
Subject: RE:
[eclipse-incubator-e4-dev] Initial discussion onthe 'modelled'workbench UI
Yves, that's interesting, especially in view of
Microsoft adding XAML to their open spec list: http://www.sdtimes.com/content/article.aspx?ArticleID=31886.
Yves,
can you point the group at some good XAML primers? Personally I'd like to
see a discussion of layout and styling v.s. CSS.
"Yves YANG"
<yves.yang@xxxxxxxxxxx>
Sent
by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
04/04/2008 03:12 PM
Please
respond to
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
|
|
To
|
"'E4 developer list'"
<eclipse-incubator-e4-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
RE: [eclipse-incubator-e4-dev] Initial
discussion on the 'modelled'workbench UI
|
|
We
have implemented XAML in Java: http://www.soyatec.com/eface. I should say
XAML is nothing in XML it-self. It has not a fixed
schema unlike XUL, just
relies on the WPF library. The key feature is the
dynamic mapping of XML
with code-behind class.
XML
Programming
language
---------------------------------
Element -> Class
Attribute -> Property
Event -> Event
There are other concepts useful such as
"attached property", "dependency
property". The "attached property"
property is mainly used to handle the
layout:
<Canvas>
<Button
Canvas.Left="10" Canvas.Top="20">
</Canvas>
The "dependency property" provides a
resolution mechanism of property
default value. It is very useful for template and
style customization.
I believe we can use the same concept for SWT
directly. We are open to
contribute our knowledge of XAML on this new
framework, even the source
codes (or directly the product) in Eclipse.
Best regards
Yves YANG
-----Original Message-----
From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
[mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx]
On Behalf Of Markus
Voelter
Sent: Friday, April 04, 2008 7:04 PM
To: E4 developer list; voelter@xxxxxxx
Subject: Re: [eclipse-incubator-e4-dev] Initial
discussion on the
'modelled'workbench UI
>>> if you look at what XUL or
Microsoft's UI markup
>>> language do (I forget the name)
>
> I think you're referring to XAML, right?
I think so, yes (as I said, I forget the name :-))
Markus
>
>
>
>
>
> "Markus Voelter"
<voelter@xxxxxxxxxxxxxx>
> Sent by:
eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
> 04/03/2008 03:09 PM
> Please respond to
> voelter@xxxxxxx; Please respond to
> E4 developer list
<eclipse-incubator-e4-dev@xxxxxxxxxxx>
>
>
> To
> "E4 developer list"
<eclipse-incubator-e4-dev@xxxxxxxxxxx>
> cc
>
> Subject
> Re: [eclipse-incubator-e4-dev] Initial
discussion on the 'modelled'
> workbench UI
>
>
>
>
>
>
>> I call this 'reinventing the flat tire'
because the result isalways
>> worse that some other 'real' wheel...;-).
>
> :-)
>
>> Ed's comment "Using EMF models would
be a boon because they would
>> directly enable a rapidly growing stack
ofmodeling technology." is (to
>> me)
>> somewhat scary because most of our
clients don't want a 'rapidly
> growing'
>> anything, they want a rapidly -shrinking-
platform (thus e4). The
> general
>> fear is that EMF may already suffer from
the 'bloat' and intra-package
>> dependencies that we're trying to
eliminate in the platform.
>
> Of course the version of EMF that would be
put to use
> in E4 would be a new, evolved version of EMF,
where some
> of these (alleged) issues could be addressed
if they really
> exist (I don't perceive EMF as big and
bloated).
>
> Also, I think being able to reuse the
"rapidly growing" modeling stack
> is actually an advantage, because it allows
E4 to really just implement
> a minimal core (e.g with a simple
scripting/CSS-like config language)
> while still optionally keeping the doors open
for more powerful
> approaches
> if people want to use those.
>
>> If we're anticipating having the model as
a 'first class' concept then
>> we're talking about placing it much
nearer to the eclipse 'core'
>> (equinox?). At this level size counts!!
At minimum I'd expect that JFace
>> would depend on it so we can provide 'modelled'
JFace viewers, etc.
> Right
>> now someone can simply get JFace/SWT and
some GUI done...how much extra
>> footprint would be needed to support EMF?
>
> just a hint: if you look at what XUL or
Microsoft's UI markup
> language do (I forget the name) than this is
very similar. Done
> right (i.e. if the minimal core is isolated)
then it's certainly
> feasible
>
>
> Markus
>
>
>
--
Markus Völter
voelter - ingenieurbüro für softwaretechnologie
Grabenstrasse 4, 73033 Goeppingen, Germany
Tel. +49 (0) 171 / 86 01 869
Email: voelter@xxxxxxx
Web: http://www.voelter.de
Blog: http://www.voelter.de/blog
Podcast: http://www.se-radio.net
PGP Public Key:
http://www.voelter.de/data/MarkusVoelter.gpg
_______________________________________________
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