Re: [e4-dev] Declarative UI

["Gorkem Ercan" <gercan@xxxxxxx>]

Declarative UI is something that we would like to utilize in the
embedded world of eSWT as well.

Actually we had a Nokia internal effort as early as 2005 that had
ended up using XSWT to implement a declarative UI for eSWT. We never
reached the end of it because we did not really have a complete eSWT
implementation on our devices at that time. The size is extremely
important to eSWT. With the XSWT based solution we we were able to run
in less than 100K of additional software. I favor a DOM based model
because we already have the plumbing for DOM available and optimized
on all places (eRCP and MIDP) we are using eSWT.

Although our experiment work was based on XSWT, I do not really favor
it over XAML. One thing that I could not really put in place on my
mind is the relation with CSS. If I recall correctly XAML can include
styling information. Are there already established rules on how XAML
works with CSS. I guess the goal is to be able to use both to form a
single model of the UI.
--
Gorkem

On Tue, Nov 11, 2008 at 11:29 AM, Tom Schindl
<tom.schindl@xxxxxxxxxxxxxxx> wrote:
> 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
>