Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] Declarative UI 
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

Back to the top