Since I won't ask someone to do something I won't myself do, :-) here's a
slightly-enhanced Hello, world in XSWT, eliminating the XML boilerplate and
imports:
<layout x:class="gridLayout" numColumns="2"/>
<label text="Hello, world"/>
<text x:style="BORDER">
<layoutData x:class="gridData"
horizontalAlignment="FILL"
grabExcessHorizontalSpace="true"/>
</text>
This is functionally equivalent to:
parent.setLayout(new GridLayout(2, false);
Label label = new Label(parent, SWT.NULL);
label.setText("Hello, world");
Text text = new Text(parent, SWT.BORDER);
text.setLayoutData(new GridData(GridData.FILL_HORIZONTAL |
GridData.GRAB_HORIZONTAL));
(This actually translates to:
GridLayout gl = new GridLayout();
gl.numColumns = 2;
parent.setLayout(gl);
Label label = new Label(parent, SWT.NULL);
label.setText("Hello, world");
Text text = new Text(parent, SWT.BORDER);
GridData gd = new GridData();
gd.horizontalAlignment = SWT.FILL;
gd.grabExcessHorizontalSpace=true;
text.setLayoutData(gd);
)
If you could translate this to XAML, Yves, that might be a useful place to
begin comparison.
Regards,
Dave
On Thu, Nov 6, 2008 at 8:02 AM, Yves YANG <[EMAIL PROTECTED]> wrote:
> So let's compare the two directions: abstraction model UI and SWT Centric
>
>
>
> 1. SWT Centric
>
> This approach consists of mapping directly from XML <-> SWT. It is true SWT
> is already an abstraction of the different UI technologies: Win32, GTK, etc.
> But it is low level abstraction: UI Widgets. It doesn't cover more advanced
> concepts.
>
>
>
> Could someone tell me why Eclipse invents a new UI Library SWT, instead of
> using Swing, which is already cross platform? From my point of view, SWT
> respects the native Look and Feel, particularly, in Windows. And Swing had
> some problems of performance, ugly look and complexity in development. This
> is a good example of courage to replace the out-of-date solution by a new
> one. Are we in the same situation? SWT is designed mainly to create the UI
> via programming. It is created several years ago. Its API doesn't full
> respect neither the model constraint, non JavaBean specification. Using it
> as main model, the new component will inherit its limitations and we have to
> add outside components to support other features such as style, data
> binding. Does it become a hybrid framework?
>
>
>
> Since the birth of SWT, the UI technology evolves quickly to markup
> language. Microsoft has the courage to give up the Win32 and invent a new
> component-based framework WPF for providing common and full integrated UI
> platform not only for Developer, but also for graphic designer and business
> analyst. It focuses on content presentation, instead of low level basic UI
> widgets. It really simplifies the UI Development.
>
>
>
> I think SWT should stay where it is designed for.
>
>
>
> 2. Abstract UI model
>
> Simply, it will give us a new land with maximum freedom to develop a
> complete, extensible UI "Presentation" Framework.
>
>
>
> Just a thought
>
>
>
> Best regards
>
> Yves YANG
> ------------------------------
>
> *From:* [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] *On Behalf Of *Kevin McGuire
> *Sent:* Thursday, November 06, 2008 12:32 AM
> *To:* E4 developer list
> *Subject:* Re: [eclipse-incubator-e4-dev] Fw: Declarative UI roundup?
>
>
> Great discussion guys. I'm only beginning to understand this area and the
> thread has been helpful. Actually my hope for the roundup is exactly this
> kind of shared understanding of the technology, and some common view of the
> goal.
>
> > The UI model tries to abstract
> > away the underlying technology by focusing on what information a widget
> supports
> > (input/output), rather than the widget API. This makes the model
> > toolkit-independent, but the runtime of course needs toolkit-dependent
> code to
> > control the life-cycle of the real widgets.
>
> Hallvard, I admit that I know nothing of your research so I'm just going to
> speak quite generally, which may not at all match what you're doing:
>
> I find this theoretically cool but with my practical hat on I'm trying to
> understand the benefit this added abstraction buys us in Eclipse. My
> original thinking was that the declarative language should map 1:1 to SWT,
> because its SWT that actually does, well, the useful stuff. The buck stops
> there. Either you can have list of strings, or a list of rendered strings
> plus images, or owner draw ... its in the capabilities of the widget and the
> only way to get stuff on the screen. In fact one can regard SWT as this
> exact toolkit independent model (if we think toolkit=platform) because it
> attempts to isolate you from platform specifics, thus the SWT list widget is
> already that abstraction of the concept of a list widget across all
> platforms. It just happens to be API based, not declarative.
>
> My concern is that inevitably when you go to an abstraction, you inherently
> lose some fidelity. Maybe some capability of a particular system you care
> about (in this case, SWT) can't be expressed because your model is a common
> subset. Or, the model is a superset, in which case you write in the hopes
> of something happening which doesn't on your particular platform. We often
> see the former case and sometimes the latter in SWT. Since I've already
> lost fidelity in SWT vs. the platform, I'm hesitant at losing more through
> another abstraction.
>
> Yves, I have a similar concern around the use of XAML since I may lose
> fidelity in going to SWT, but that's perhaps more a statement of my
> ignorance of XAML.
>
> Thus my thinking was perhaps along the lines Tom outlined: a declarative
> model written against SWT, exposing accurately the capabilities of SWT but
> in a serializeable format instead of Java code, providing a model which
> facilitates mapping to other declarative models.
>
> So I question, why do I need yet another abstraction? I guess it would let
> me go to Swing, which personally I'm not interested in. Maybe it would allow
> me to go the web, but SWT is going to do what it always does and treat it as
> a platform. Unless you believe there is an inherent flaw in doing so which
> a common abstract model solves? I suppose it could allow me to reuse parts
> of UIs (e.g. some pre-canned wizard pages), but in my experience you always
> roll a UI that is specific to a problem area. Finally, it allows me to
> escape a particular programming language, (Java, yeah!) but I think I get
> that from the declarative aspect, not the common abstraction. What am I
> missing here?
>
> > The main problem with going through XML and a renderer, is that it only
> handles
> > the creation process. I still need (in my case) SWT-specific code for
> attaching
> > listeners and activating/deactivating widgets.
>
> <naiveQuestion>Isn't this solved to a great degree through the use of
> databinding?</naiveQuestion>
>
> Regards,
> Kevin
>
>
>
> *Hallvard Trætteberg <[EMAIL PROTECTED]>*
> Sent by: [EMAIL PROTECTED]
>
> 11/05/2008 09:00 AM
>
> Please respond to
> E4 developer list <[email protected]>
>
> To
>
> E4 developer list <[email protected]>
>
> cc
>
>
>
> Subject
>
> Re: [eclipse-incubator-e4-dev] Fw: Declarative UI roundup?
>
>
>
>
>
>
>
>
>
>
> Tom and others,
>
>
> Just a bit of background: My research field is model-based UI design and
> the
> last years I've been building a UI modeling tool (see
> http://www.idi.ntnu.no/~hal/research/<http://www.idi.ntnu.no/%7Ehal/research/>).
> The editor is based on EMF+GMF, while
> the runtime is built on a Apache SCXML (a statechart engine) for activation
> of
> UI parts, EMF databinding for dataflow, XSWT for describing the concrete
> UI, EMF
> for modeling the domain and Javascript (Mozilla Rhino) for scripting (both
> behavior of the model and scripting of XSWT). The UI model tries to
> abstract
> away the underlying technology by focusing on what information a widget
> supports
> (input/output), rather than the widget API. This makes the model
> toolkit-independent, but the runtime of course needs toolkit-dependent code
> to
> control the life-cycle of the real widgets.
>
> To make the runtime a bit more flexible, it does not build the widget
> structure
> directly, but generates an XML file (in my case XSWT) that is then rendered
> by a
> library. The idea is that it should be fairly easy to use any XML-based UI
> description language.
>
> The main problem with going through XML and a renderer, is that it only
> handles
> the creation process. I still need (in my case) SWT-specific code for
> attaching
> listeners and activating/deactivating widgets.
>
> > b) Ed is right I think we need a more strongly typed / constrainted
> > description language.
>
> Strongly typing is desirable. But just as important is a uniform way of
> manipulating the widget structure. By using DOM or EMF, we can manipulate
> and
> listen to standardized objects. The mapping to the toolkit API is handled
> by a
> toolkit-specific library, containing all necessary toolkit-specific logic.
> I
> believe this is Angelo's approach, although he uses DOM rather than EMF.
>
> > As I have understood TK-UI so far it uses XUL to described the UI so
> > Angelo has a constrainted description language it only misses an
> > Ecore-Description [1,2].
> >
> > What I often thought about is that we could have a layered approach here:
> >
> > XAML XUL MXML MySpecialML
> > | | | |
> > ------------------------------
> > |
> > | Transform (XSLT, ....)
> > |
> > SwtXL => EMF-Modeled SWT-API
> > |
> > SWT-Application
> >
> > This is the concept I currently have in mind for my UFaceKit-Project the
> > only thing I replace there is SWT through UFaceKit and SwtXL through
> > UFaceKitXL.
>
> I don't like the idea of having an SWT-specific model, so UFaceKitXL (EMF
> model
> of UFace widgets) is preferable. I guess it is more difficult to make a
> toolkit-independent model for UFaceKit than one for SWT? E.g. how do you
> handle
> things like content providers and cell renderers/editors?
>
> As mentioned, the model is one thing, how it reacts to changes is another.
> Is
> UFaceKitXL designed to handle changes to the Ecore objects, like
> adding/removing
> widgets, changing attributes etc? I have implemented good support for Ecore
> in
> Mozilla's Javascript, so being able to manipulate the UI through Ecore has
> great
> potential.
>
> > I've already tested this approach in a project I had named EXSWT the
> > only thing missig there was the Ecore-Model for EXSWT [3].
>
> Which was based on XSWT, wasn't it? I've worked a lot on and with XSWT and
> its
> main problem is that (although the language is/looks declarative) it is not
>
> designed to handle a live model, i.e. react to changes to the DOM.
>
> Hallvard
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>
>
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
