Browse DevX
Sign up for e-mail newsletters from DevX


SWT, XML Put True Cross-platform GUIs Within Reach : Page 2

The reality of a single cross-language, cross-platform GUI interface programming model is in sight, based on an XML description language supported by fast native runtimes. Will Mozilla, Eclipse, or someone else step in and complete the last mile that gives all developers a common way to design and program fast cross-platform user interfaces?




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Open Source, Cross-platform
Both XUL (Netscape and Mozilla Public Licenses) and SWT (Common Public License) are open source cross-platform technologies; anyone is free to implement the specifications in any language and on any platform they prefer. Even though SWT is currently available only for use with Java, there's no reason for that to continue; it would be perfectly possible for IBM or some other organization to create .NET-compatible (CLR-compatible) versions. If that happened, we would see Microsoft, IBM, and Sun each with a big piece of the development pie; Microsoft with the CLR, Sun with Java, and IBM with the cross-platform desktop connection for both .NET and Java.

So, naturally, for anyone anticipating a fully cross-platform .NET development environment, the question becomes: What are the open source .NET projects, Rotor and Mono, planning for GUI development? As it turns out, both projects are implementing the Windows.Forms namespace (which is not part of the CLR) on their respective platforms. As far as I can tell, neither project is attempting to use any alternative GUI representation. That could be a mistake. It's going to be a huge effort to get the Windows.Forms namespace implemented on any particular platform, and that effort isn't going to translate easily to any other platform, nor will the resulting forms translate easily to other languages.

In contrast, both SWT and XUL have already been implemented, at least experimentally, on several platforms, so the technology is already proven even if it's not yet used extensively. Because both SWT and XUL specifications are open source, any alternative CLR implementation should be able to tap into the code of either one far more easily than performing a complete feature-for-feature rewrite of Windows Forms.

Moreover, any CLR/SWT or CLR/XUL implementation would also conceivably run on Windows, which would give current Windows developers an incentive to use it and would bring Java and .NET that much closer together.

To the Swift Go the Spoils
Frankly, I'm surprised that Microsoft didn't include the Windows Forms specification in the CLR, as they've now created an opening for IBM, Mozilla, or another third party to provide an alternative GUI model that works not only across platforms but is also relatively independent of the language used to activate it.

Further, if Mozilla were to take on the project of connecting XUL to SWT, developers could design cross-platform GUIs in a completely language-independent fashion. For example, by designing an application interface in XUL and using the appropriate platform-specific SWT implementation to activate it in the language of your choice, the only thing you'd need to change from one platform to another would be the SWT runtime. It's a powerful combination and opens a window of opportunity for any organization with the vision to implement it.

I doubt that Microsoft will leave the window open long; the company has been discussing a unified forms model for years. Further, Microsoft has experience generating XML-based forms in .NET, and while its model has not been adopted universally, it would be relatively easy for it to switch to some other XML representation. Obviously, Sun is in much the same shape. With SWT, platform-specific code has obtained a toehold in the otherwise unmarred surface of pure Java. There's been a good deal of discussion about whether Sun should embrace SWT, although so far, they've clung to Swing tenaciously.

Meanwhile others are also looking at ways to improve Java's GUI capabilities. At least two attempts have already been made at delivering XUL-specified interfaces to desktop machines. Martin Weindel's Luxor XUL marries XUL to SWT for Linux and Java. Another project, XWT, provides a browser-based XUL rendering engine as both an ActiveX control (IE) and a Java applet. Marc Erickson, Project Manager, OTI Marketing and Sales (of OTI Embedded Systems), says OTI Labs has done similar work for the embedded community in an offering called P3ML. So there's at least some movement in the development community.

Although these projects point the way to truly cross-platform GUIs, a broadly successful effort will need multi-vendor buy-in and support. The XWT FAQ presents the arguments for using XUL and discusses some problems.

Developers don't need multiple programming models for common widgets, such as windows, list controls, outline controls, drop-down menus, textboxes, and buttons. Widgets act much the same between platforms and the differences that do exist lie almost exclusively in the look and feel (how they're rendered and the events they raise). In short, the enormous efforts expended by developers who learn more than one GUI programming model interface are largely wasted, because the results are visually and functionally nearly identical yet remain quite different from a development point of view. I fully expect that an XML-based forms description language, backed by platform-specific, high-performance runtimes will eventually capture both the market and developers' mindshare.

A. Russell Jones is the Executive Editor of DevX. He can be reached at rjones@devx.com.
Thanks for your registration, follow us on our social networks to keep up-to-date