XSWT: XML UI motor for SWT

Hi,

  Chris McLaren from IBM Canada filed a "bug report"
for Eclipse titled "consider a UI markup language for
SWT".

Chris writes:

<quote>
XSWT is a markup language for describing composites of
SWT widgets, including descriptions of the layouts,
constraints, and other properties of the widgets. XSWT
tries to remain 1-1 to SWT to reduce the learning
curve. By being XML, it is ideally suited to be
produced from an XSL transformation from other,
perhaps higher level yet-to-be-invented UI markup
languages.
<quote>

I guess they "higher level yet-to-be-invented UI
markup language" alluded to is XUL.

Chris lists the following pros for XSWT compared to
hard-coding your UI in Java:

1. Reduce code significantly. Analysis of random
preference page code in Eclipse, for instance, shows
that often 2/3+ of the code is dedicated to creation
of the composite. Consider a simple example:
WorkbenchPreferencePage(org.eclipse.ui.internal.dialogs).
It is 377 lines long (as I write this), of which 226
lines (line 46 to line 272). These 226 lines can be
replaced by approximately 30 lines of XSWT code.

2. Laying out controls can be tedious and time
consuming for the developer. XSWT allows this work to
be split - a UI designer, product manager, etc. could
provide XSWT markup to the developer. XSWT markup
could be passed around easily via email and anyone
with the XSWT plugin could instantly view, compare,
modify, make a copy of, etc, without having to be in a
java development context.

3. Even for developers that master complex layouts,
they are still often affected by 'clerical' errors,
and they usually require a iterative code-run cycle to
look at and tweak their composite in its context, for
example, running Eclipse and going to your preference
page to have a look at how its coming along. The
ability to see your composite generated on 
the fly should reduce time here.

4. Increase maintainability: Dialog and Preference
page classes are typically monolithic classes, often
greater than 1000 lines. XSWT not only reduces lines 
(1.) but formalizes the widget creation in a manner
stricter than java provides. i.e. many 'dialects' of
Dialog and Preference page classes can be found - some
developers create all their widgets in one method,
while others dispatch to a variety of custom,
semi-reusable methods. A developer who wishes to
change these classes must spend the time to understand
whereto best add their widgets in the code.
Formalizing this process into a single XSWT file
should increase maintainability.
 
Now I hope I don't get sued for this massive quote.

Chris is not all talk to quote: "All this being said,
the actual code to implement XSWT in eclipse (along
with the viewer) is quite simple, and took only a few
hours to write."

Let's give IBM a warm welcome to the world of XUL.

 - Gerald

Full story @ https://bugs.eclipse.org/bugs/show_bug.cgi?id=38109


-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5