Re: [e4-dev] Declarative UI

[Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>]

Hi Tom,

Excellent points.

> I'd argue that someone is not even getting access
anymore to the REAL
> widget when he/she is using declarative UI.

Right, it all hinges on this assumption
which I don't believe is true in all cases.

But first I believe we first need to
answer the question of what our model is a model of.  You touched
on this below when you said you are no longer a fan of XSWT.

1) If we believe the model is just a
model of SWT, but permitting a declarative syntax for construction, then
I believe that it has to match 1:1, pound for pound, the capabilities of
SWT. 

Put another way, if you found it important
to be notified of visibility change, then why didn't you just fix this
in SWT?  Is it because you don't have access to that code?  Is
it because all the platforms don't support it?  You had a fight with
the SWT team? ;-> 

The problem is that in any mature code
base, there will be legacy code that is written directly against SWT.  Now
their calling setVisible, and you going through the model, have two different
behaviours.  How can you rely on the notification? Its only useful
if you are guaranteed nodoby else is accessing the widget.

2) If you believe the model is a higher
level abstraction, then I think you can start to decide to provide additional
capabilities.  Now the model isn't one of SWT but of something else
(not sure what yet).  That something else might maintain additional
state, provide new semantics, new capabilities.  OK you still have
issues with legacy code but maybe you can start to argue that the trade
off is more compelling.  I guess now that I write, this is the argued
case of UFace.

I regard the workbench model to be this.  Its not actually a model
of the current workbench implementation, but a model of some new abstraction
of what a workbench is at it essence, providing simplified/rationalized
access.  But we're not about to nuke all the existing workbench API
and people for legacy reasons will always be able to write directly against
the underlying parts.


Before we get embroiled in the syntactic
and technical differences of the various declarative approaches, I believe
we need to first answer this question of what we think we should be modelling
and why.  As a general statement, if its going to be something other
than a model of SWT, then I'd like it to be a lot more, for the simple
reason that it actually helps if its different enough to the existing so
I don't get confused, and powerful enough so its worth my investement in
learning.

Regards,
Kevin

Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>
Sent by: e4-dev-bounces@xxxxxxxxxxx

11/12/2008 03:03 AM

Please respond to
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>

To	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
cc
Subject	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
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev