John O'Conner's Blog

SwiXml alternative for Java GUIs

I don't want to declare Java's code based layout dead yet, but I think a new way of creating GUIs must be considered. One of the huge benefits of coding on the Microsoft platforms has been their great tools and support for creating user interfaces with a simple resource language. You remember .rc files right. You could edit them in any editor. Localization tools everywhere support this file format. Well, Java's traditional method for laying out a form just isn't very easy to localize. Sure, you can stick text in a ResourceBundle, but that doesn't do anything for the layout.

"But layouts are handled by Layout Managers," you argue. "We don't need any stinking resource language to describe our layouts. They resize automagically, blah, blah, blah."

Yes, we do need something different. Things are changing…fast. People…engineers…are tired of creating UIs in Java code, tying views with controllers. Localization vendors don't like dealing with java source code files to localize a UI. They can handle the text resource bundles, but give me a break with the form or window itself coded in Java! There must be something better. And there is!

I'm just discovering this myself, so I still have lots to learn. However, this thing called "SwiXml" has potential for becoming the GUI layout tool for Java developers. As the name suggests, SwiXml is an XML document. It can describe standard Java UI components in XML. Although you still have to understand Java layout managers, you don’t have to understand the Java language to understand what the UI will look like. And that's perfect for localization people who just want to translate and localize the UI.

You have to read more about this. Hopefully we'll see some localization tools that can read and display these files visually, showing immediately and exactly how the localization engineer chooses to translate and localize the layout.

I'm convinced that a declarative XML file will be the standard for Java GUI design and layout in the future. It's gonna happen, so better start looking at this now. This…or something very similar…will be the standard for creating Java user interfaces.

Study up now. Here’s a little appetizer from Joshua Marinacci, a Swing engineer at Sun: Building GUIs with SwiXml.

Then when you're ready for more, head on over to the web site: SwiXml.org

Comments

• Look closely at the labels in Joshua's simple example - they're misaligned! It's the SpringLayout tutorial yet again.

  Moving code into XML doesn't help. It's not even as if XML is any more readable than good Java (totally GridBag does not count as good Java in my book).

  Posted by: tackline on May 04, 2006 at 01:04 PM

• I personnaly think that the best solution lies in the tools, in GUI Builders and IDEs. If my tool let me bind data to components (and components to components) and let me create my windows very quickly, then I am happy. I don't care whether it's code or XML or whatever behind the scenes; I just want to use my tool. We already have the quick GUI design tool with Matisse, now we need visual data binding support. XML and code are only implementation details which I couldn't care less about. XML as some interesting points over code (deployment of new screens or tools interoperability) but then again, I don't care, I want the tools :)

  Posted by: gfx on May 04, 2006 at 02:10 PM

• SwiXML does a good job fullfulling it's purpose in life, which is to recreate standard Swing layouts in XML. That the XML is still complicated reflects the failing of the standard layout managers, not of SwiXML. I agree with Romain that the future is in GUI tools. Layout is an inherently visual task that needs a visual tool. We need a standard storage mechanism for the layouts, which will most likely be some form of XML, but that is for the benefit of cross-tool support, not so you can edit by hand. In fact, I'd prefer it to be a binary blob so that people would not be tempted to edit it by hand. Use the right tool for the job!

  Posted by: joshy on May 04, 2006 at 03:37 PM

• Hi John,

  I was intrigued by the various XUL dialects out there (such as SwiXml) a few years ago, but like others have said, I think the window when those tools could have become mainstream is past. High-quality WYSIWYG visual layout tools have finally arrived, and I think they're infinitely superior to hand-coding. The biggest role a declarative UI layout format can play in this era is in standardizing how GUIs are serialized, perhaps enabling developers to use different UI tools on the same layout files.

  Ben

  Posted by: javaben on May 04, 2006 at 11:24 PM

• I don't think I've been clear. I agree that tools are the way for defining layouts. No question there.
  The big issues that interest me are these:

  The XML layout is portable across platforms and tools. The file format makes it convenient and easy to make tools to help create and edit it.
  People who really understand UI can concentrate on the layouts and components without worry about screwing up Java code. They can concentrate on the primary object of their interest (the UI layout) without the distraction of Java code. Great tools makes the job easier...that's a bonus. The fact that this format distills the essence of the user interface without the distraction of Java code makes it a winner in my book.
  UI creations rendered from programmatic code present one nasty problem for translators and localizers. Perhaps the problem wouldn't be as bad if Java coded UIs were pure views. Instead, however, most Java views have controller code snugly embedded in the same class file. The tight link just causes fits for translators and localizers. Yes, better tools could help fix this, but in their world, the tools work very well for declarative text files that present just what they need...the layout and/or text of the UI.

  Hey, don't get me wrong, tools are great. But if you can isolate the UI into a simple file format, the tools don't have to be nearly as sophisticated. That's true for the originual UI designer as well as localizers that pick up the file later. I like that.

  Posted by: joconner on May 05, 2006 at 12:55 AM

• I have heard great things about Matisse, so far. I myself use JFormDesigner which is one of the currently available 'great tools' mentioned in the other comments. The fact that it is a commercial tool, although not expensive, takes it out of the race for a lot of developers, mostly those creating OS software.
  For Netbeans/Matisse, some Eclipse plugins and numerous other tools on the market it may be worth a minute thinking about choosing for example SwiXml as (alternate) storage format. This would combine the benefits of both pieces of software and you wouldn't have to write yet another Swing UI designer (although YASUD may be a catchy name).

  Posted by: pronger on May 05, 2006 at 01:00 AM

• IMHO, CookXml / CookSwing (http://cookxml.sourceforge.net) is a much better XML gui motor than SwixML, because it has a modular, extensible architecture and features scripting (optionally).
  

  Posted by: dmoebius on May 08, 2006 at 07:28 AM

• There is a new GUI builder tool for SwiXml called SwixEditor at http://www.invivosoft.com/swixeditor

  Note: I'm an employee of the company that has developed swixeditor.

  Posted by: sankumar on September 15, 2006 at 05:20 AM

• Hi John,

  This is a relatively old post but I was curious how long it might have been since you gave SwiXml a glance. Since this last mention is a year and a half old.

  I've been working with Java for 10 years. I've been working with Adobe Flex nearly 99% of my time for the last 10 months.

  All this time I've been interested as Applets coming back. If it were possible.

  JavaFX sparked an interest but working with the script has its small hurdle of familiarity or syntax for some, including myself.

  So my comment is that coming from MXML, but being from a Java background SwiXml for me is like me being a duck taking to water.

  I've only taken, just now, a cursory glance but it's very interesting. I would suspect that the XML mark-up is an alternative approach which would be taken up much more easily and widely than JavaFX script.

  My two cents.

  Posted by: szermierz on April 24, 2008 at 09:18 PM

This work is licensed under a Creative Commons License.