[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [e4-dev] Declarative UI
|
Hi Gorkem,
> 1.) Specifying external CSS. Yves's suggestion sounds good. Perhaps we
> also need a title so that several css files can be
> activated/deactivated.
> <Style file="style.css" title="mystyle" />
One Style can be defined for a specific type. The following example applies
the style to all children of type Label.
<Window
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation";
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml";>
<Window.Resources>
<Style TargetType="Label" file="style.css" >
</Style>
</Window.Resources>
<Label Content="Hello"/>
</Window>
We can also name a style, and each element can select one by name
<Window
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation";
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml";>
<Window.Resources>
<Style TargetType="Label" file="style.css" >
</Style>
<Style x:Key="Style1" TargetType="Label" file="style1.css" >
</Style>
<Style x:Key="Style2" TargetType="Label" file="style2.css" >
</Style>
</Window.Resources>
<Label Content="Hello1"/>
<Label x:Style="{StaticResource Style1}" Content="Hello1"/>
<Label x:Style="{StaticResource Style2}" Content="Hello2"/>
</Window>
The first Label uses default style for Label. The second Label uses the
style1, and third uses style2
Is it what you want?
>2.) The Style element. In this case supporting the CSS style selectors
> is more powerful.
Yes, great idea.
Regards
Yves YANG
Soyatec - Eclipse OutSourcing & XAML for java
http://www.soyatec.com
Tel: +33 1 60 13 06 67
Mobile: +33 6 20 74 39 45
Fax: +33 9 58 07 06 67
-----Original Message-----
From: e4-dev-bounces@xxxxxxxxxxx [mailto:e4-dev-bounces@xxxxxxxxxxx] On
Behalf Of Gorkem Ercan
Sent: Wednesday, November 12, 2008 11:23 AM
To: E4 Project developer mailing list
Subject: Re: [e4-dev] Declarative UI
We should be able to support several ways of using CSS.
1.) Specifying external CSS. Yves's suggestion sounds good. Perhaps we
also need a title so that several css files can be
activated/deactivated .
<Style file="style.css" title="mystyle" />
2.) The Style element. In this case supporting the CSS style selectors
is more powerful.
<Window
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation";
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml";>
<Window.Resources>
<Style>
Label {
color: #FFFFFF;
}
#helloworld {
font-size: 75%;
}
#helloworld Label{
font-family: Arial;
}
</Style>
</Window.Resources>
<Label Content="Hello" id="helloworld" />
</Window>
3.) And of course the inlined styling information.
<Label Content="Hello" Color="Blue" />
These basically map nicely with Style Sheets in HTML, I think the same
cascading rules would apply.
--
Gorkem
On Wed, Nov 12, 2008 at 10:03 AM, Tom Schindl
<tom.schindl@xxxxxxxxxxxxxxx> wrote:
> Hi Kevin,
>
> Can you clarify this? I don't see a problem with going through the DOM.
> I'd argue that someone is not even getting access anymore to the REALLY
> widget when he/she is using declarative UI.
>
> You may ask why does one not have access to the widget:
> a) Did you ever see a WebDeveloper trying to access the real
> Native-Gecko-Button? SWT is just a renderer of the widget
> like Gecko, ... is in a browser.
>
> b) The DOM you are seeing and the Widget-Hierarchy don't necessary have
> a one-to-one mapping. E.g. let's say I want to have fancy border
> drawing in SWT then my DOM looks like this:
>
> <composite border="black 2px" layout="grid">
> <label text="BlaBla 1" />
> <label text="BlaBla 2" />
> </composite>
>
> whereas the widget structure is like this:
>
> Composite (FillLayout=margin=2, backgroundColor=black)
> Composite(GridLayout)
> Label
> Label
>
> c) What do you script against? The real widget is not right IMHO because
> of 2 and 3
>
> The above example of a border is the reason I'm not a friend anymore of
> a low-level dialect like XSWT but favor some higher level of Declarative
> UI. As long as I programm against the high-level DOM it doesn't bother
> me how a feature gets implemented at the widget-level
> (widget-composition, gc-drawing, ....). Naturally the above border could
> get implemented also by subclassing Composite + PaintListener but I
> guess you'll get the point, right? By the way how is such a problem
> solved when the border definition is coming from an CSS-Stylesheet?
>
> When we talk about modeling the workbench it even gets worse because
> e.g. a StackedPart can get rendered by a completely different
> widget-type for example:
> - CTabFolder
> - TabFolder
> - Nebula-PShelf
> - ...
>
>
> Tom
>
> Kevin McGuire schrieb:
>>
>> Actually this approach concerns me: if I go through the model, or go
>> directly against SWT, I get different notification. It could easily
>> lead to bugs in application code. I would also argue that the model is
>> then no longer a model of SWT, but rather, a model of an enhanced SWT
>> which doesn't exist.
>>
>> Regards,
>> Kevin
>>
>>
>>
>>
>> *Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>*
>> Sent by: e4-dev-bounces@xxxxxxxxxxx
>>
>> 11/11/2008 04:29 AM
>> Please respond to
>> E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
>>
>>
>>
>> To
>> e4-dev@xxxxxxxxxxx
>> cc
>>
>> Subject
>> Re: [e4-dev] Declarative UI
>>
>>
>>
>>
>>
>>
>>
>>
>> Angelo zerr schrieb:
>>> Hi,
>>>
>>> I would like speak about UFace <http://code.google.com/p/uface/> that
>>> I'm using into TK-UI <http://tk-ui.sourceforge.net/index.html> and I
>>> find very helfull to manage Declarative UI. With TK-UI you can describe
>>> UI with any XML Markup (XUL, XHTML,...) and render it into any renderer
>>> (SWT, SWT Forms, Swing...) Today I'm using UFace which is UI facade
>>> which provide a lot of think like Databinding (based on JFace
>>> Databinding). I like UFace because anything can be bounded :
>>>
>>> * UI widgets : any properties of (visible, text... properties if UI
>>> widgets). For instance if you call setVisible, it fire event so it's
>>> possible after to observe this property (with SWT we cannot catch this
>>> visble event for instance).
>>
>> This is a very interesting point Angelo is raising here. I think when we
>> describe our UI and directly interface with SWT people HAVE TO program
>> against the DOM (whether it is EMF or anything else) and not directly
>> against the widget because changes in the UI like setVisible(),
>> setEnabled(), ... can't be synced back live to the declarative model
>> simply because SWT is not informing us about these changes with events.
>>
>> I don't see this as a problem though. By the way in "Modeling the
>> Workbench" we identified only a hand full of things where we need to
>> sync back from the Widget (e.g. Resize, Iconify, ...) to the model. We
>> assume that *all* other operations are happening on model and are then
>> reflected in the UI.
>>
>> Tom
>>
>> --
>> 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
>> _______________________________________________
>> e4-dev mailing list
>> e4-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> e4-dev mailing list
>> e4-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>
> --
> 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
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
