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

Back to the top