Resource-Based GUIs Vs. Code Generators In Java

Java Fan writes, "There is a good debate about GUI generation tools for Java going on at theserverside.com: 'Almost every platform has a visual designer that serializes the GUI to resources (some XML, some proprietary binaries) and then attaches it to the controller at runtime. Apple has had this for years with Interface Builder, Vista has a similar philosophy now as well. Java developers though are left with either hand coding of GUIs or potentially messy and brittle code generators. Neither of which promote good MVC separation. In fact they tend to encourage violations unless you are a very disciplined coder.' Personally, I am partial to BuoyBuilder as a great solution to this issue."

Gee, what a deal!

300 bucks for a crappy UI builder that adds multiple layers of abstraction on top of Swing! That sure is cheaper than Visual C# Express, Interface Builder, SharpDevelop, wxWindows, Visual Basic, or any of the GUI builders available for Eclipse!

Wait, no, sorry. It's not.

Nice slashvertisement.

Re:Gee, what a deal!

Cost is irrelevant. Quality is the only measure.

That's the ivory tower answer, and from a certain perspective it's true and from a certain perspective it's not.

The last Java shop I worked in wouldn't pay for any development tools. Good tools that were free (as in beer) or close to it were at a premium.

The Difference Between Theory and Practice

In theory, I'm not against the use of a GUI builder as long as it provides a way to use all of the layout managers that are available. I've just never seen one that could scale in complexity to the needs of a real world application. Sooner or later, the functionality requirements drive GUI elements to be created based on configuration settings and/or business rules. That is where you hit the wall with the GUI builder.

XMLEncoder/XMLDecoder

Almost every platform has a visual designer that serializes the GUI to resources (some XML, some proprietary binaries) and then attaches it to the controller at runtime.

Anyone who's interested in this issue should look into the java.bean.XMLEncoder [sun.com] and java.bean.XMLDecoder [sun.com] classes. These classes are able to serialize and deserialize complete GUIs. In the past, I've used the Netbeans GUI Builder to develop throw-away GUI frontends, then serialized them to a file rather than using them directly. I then built a framework that used the little-known "Name" property on AWT/Swing components to attach actions.

The results were quite good. Not only was the GUI decoupled from the code, but development was actually accelerated as minor GUI hiccups had no effect on the rest of the codebase. The downside was that the XML occasionally had to be tweaked to perfection as the XMLEncoder class was not 100% perfect in serializing some of the finer details.

A few years ago I spoke with one of the Netbeans developers about making the XMLEncoder format the standard for Netbeans. The idea was met with some resistence, seemingly because there was no actual Java-standard framework to target. The JVM base libraries have the Encoder/Decoder routines, but all the rest of the work must be done by the programmer. (Such as attaching the actions to the components.)

Neither of which promote good MVC separation. In fact they tend to encourage violations unless you are a very disciplined coder.

Train yourself to use Swing Actions. It seems like you're creating hundreds of little objects, but what you're really doing is encapsulating actual actions in the system away from their physcial controls on screen. So if you have a button, a menu item, and a toolbar item that all do the same thing, a single action can control all three widgets. This helps smooth out issues like keyboard shortcuts, which can get quite confusing when coding a Swing application.

Re:XMLEncoder/XMLDecoder

Can we get something more like GTK or something with a nice cross-platform *standard* GUI toolkit?

The problem isn't the toolkit. It's the lack of a standard serialized form. In the Windows world, the standard format is known as a "resource file". Since all GUI editors target this resource format, there is no compatibility issues across IDEs. Similarly, GTK+ standardizes on GladeXML from the Glade Interface Designer [wikipedia.org]. So there's no question about what format an IDE should support when adding a GUI Designer.

Swing is one of the few GUI technologies that doesn't have a standard serialized format. The XMLEncoder technology took a step toward solving this, but didn't follow through. The result was that we had a format, but no library to actually wire up a deserialized GUI! (e.g. GladeXML is decoded by libglade) This oversight was rather massive, but ended up being ignored as the focus continued to shift toward server-size J2EE development.

GINAC

We started a project along the lines of Interface Builder with a Java Swing implementation for our master's thesis in 2005. It's called GINAC, as in GUI Is Not Application Code [ugent.be].

As I really hate designing GUI's in code, I've started working on it again lately, currently implementing something along the lines of cocoa bindings. If anybody is interested in helping out, let me know!

Re:GINAC

You should just go the extra few feet and call it "Visually Activated GUI Is Not Application Code".

Huge oversight on Sun's part

I'm not sure how they released without some sort of GUI building tool. I haven't used Java in awhile, but I remember coming up with Shakespearean-esque curses to describe what I thought of GridLayout and their buddies.

Is there an accepted good builder now? The article seems to imply this is far from a solved problem. (10 years later!)

Re:Huge oversight on Sun's part

I haven't used Java in awhile, but I remember coming up with Shakespearean-esque curses to describe what I thought of GridLayout and their buddies.

I'm guessing you really mean GridBagLayout, since GridLayout is a different and very very simple layout.

I realize GridBagLayout is hard to learn, but over the years I've learned that you cannot avoid it.

Sun has tried [sun.com] three [sun.com] times [sun.com] to make a "simple" replacement for GridBagLayout. Each attempt utterly fails as a replacement (but each is useful for some other rare types of layout needs).

I've tried to make my own "simplified" version of GridBagLayout too. In fact, I suspect nearly every intermediate Java GUI programmer tries this at some point; it's almost a rite of passage. And it's always a failure. The reason is that UI layout simply is that complicated, and there's no way around it. If you think it's simpler, then you probably aren't aware of all the issues involved.

A UI builder won't make it any simpler. It will just make it easier for you to ignore the issues. The usual result of such "freedom" is that the resulting UI looks acceptable, but doesn't have acceptable behavior. For instance, to pick a simple case, a scrolling list doesn't resize when the window containing it resizes.

Faces in the Crowd

Possibly Java's greatest strategic feature is the classloader that can dynamically retrieve classes across the network at runtime and safely instantiate them. If Java had a standard API and data format for de/serializing UIs that accommodated their remote contexts, applets could become much smaller and dynamically bound to the UI facilities of their arbitrary runtime platforms. If these mobile UIs were componentized with a consistent internal API, applets could share UI elements among themselves on the same host. That architecture would not only reduce distribution size and increase flexibility, but it would promote reuse of the same UI components across applets, increasing user productivity with fewer learning curves.

If those APIs don't already exist, reusing an existing one, especially Flash, would offer possibilities for reusing existing components or patterns already populating the Net.

Java could increase its stature among distributed architectures. And make our lives easier.

Never heard of Matisse eh ?

Java developers though are left with either hand coding of GUIs or potentially messy and brittle code generators.

Whenever it comes to Java it always amazes me how many people have very outspoken opinions about it while its almost immediatly obvious that they hardly know what they're talking about. Then again, when reading the article its becoming obvious that when he's talking about GUI's (since when do you code in a GUI? I use an IDE for that) he actually means to say Eclipse. Don't get me wrong: I'm not dissing Eclipse here, but do question his bias.

When it comes to building GUI's Java really allows itself to be used by code generators IMO simply because Java is very modulair build. The only problem you might face here are the somewhat limited layout managers. For the non-Java people amongst us: these basicly define the "interface" between the GUI you're building and the way it behaves. For example; when it comes to resizing or placing of the objects then you're dealing with a layout manager.

Now... When it comes to Java IDE's two names immediatly spring out: NetBeans [netbeans.org] (my personal favorite) and Eclipse. Now that he has commented on the latter let me comment on the first. From NetBeans 5.0 and up it comes with a fancy GUI builder codenamed "Project Matisse". Its official name is now NetBeans Swing GUI builder [netbeans.org]. After taking a closer look at that I wonder if he still thinks that there are no decent GUI builders available for Java.

The real problem here isn't so much the GUI builder but the underlying layout manager which needs to keep things in check. I think that also explains why there isn't much of this available as it looks to me as if there aren't many people about who manage to come up with decent Java coded tools which can be used and adopted by many other coders. NetBeans has solved all this by introducing a layout manager of their own, the so called Absolute Layout. Pro's are its extreme extensiveness, the con's are that if you wish to use it you'll have to ship it with your software because its not part of the standard Java Runtime Environment (JRE).

If you wish to see a demo of Matisse in action then check out the NetBeans flash demos [netbeans.org], especially the first part of "Why NetBeans?". Personally I'd recommend another approach, namely simply downloading NetBeans [netbeans.info] and trying it out for yourself. Its available for Linux, Solaris, Windows and I think even OS X.

Interface Builder

> Apple has had this for years with Interface Builder

Presumably NeXT has had it for even longer, a couple of decades or there abouts. IB was written by a brilliant French coder as I recall... he was a friend of a colleague. Short of firing up my NeXTBox does anyone remember more of the history?

Hybrid approach for fast dev - good code

I find that the code generators/visual dev environments never create truly maintainable code that adheres to good coding conventions/standards when working with a reasonably complex user interface design.

My approach is to use the GUI designers to quickly prototype the UI and for fast proof of concept. Once I am pretty close to the requirements, it is time to refactor to good coding standards.

With regard to Java, the only approach that I have seen that is flexible and maintainable is to provide the correct getters/setters for Introspection (e.g. a JavaBean) so that your GUI Widget can be manipulated by a Visual designer for future use in other UI's and for maintenance.

Just Use Swing

XML-based Swing GUI tools are really a dime a dozen, and always seem to add an extra layer of complexity to Swing-based apps. Swing is a really nice component system, and pretty much every object is easily extendable. Personally, I have tried a good deal of the XML-based systems, and really using Swing as it was intended is the way to go. Build your own components, extend them, combine them. I know that there is this idea that you hand over the frontend to a designer, but we all know that most of the time it is the developer hacking on the frontend.

I can understand why people think they need XML-based systems. So much Swing-based code sucks ass. Putting all of your buttons and frames in a big-ass method is nasty and hard to maintain. Well-thought-out componentized Swing code is easy to maintain and nice to look at. Plus, once you are finished with your project, you can re-use any components you built. Swing is a great library - more people need to just learn it.

IBM's AUIML

I find IBM's AUIML to be an amazingly good solution. You can design the GUI with a visual tool and write code that runs in Swing as well as in a web server (as a web or portal application). Here's a link to AUIML page on AlphaWorks: http://www.alphaworks.ibm.com/tech/auiml [ibm.com] Download seems to be outdated at this time. Look for version 6.x if you want to give it a try.

Apache Velocity

I've been developing a lot of applications lately with J2EE (thus Webbased). There are some cool things happening there, for example good integration with JSF and Dreamweaver. This lets designers use Dreamweaver while the programmers are programming the back-end.

Also one thing that might be worth looking into is Apache's Velocity, templating at a whole new level.

Glade

The Java-Gnome Project [sourceforge.net] uses Glade [gnome.org] to build a serializable (to XML) GUI.

Hand coding GUIs

I see nothing wrong with this.

Hand coding may not promote a clean separation of concerns, but it does nothing to preclude it. Interface generation does not ensure a clean separation of concerns. In fact I doubt that it does anything significant to promote it.

The problem is that the controller tier is still a user interface component, which many engineers don't seem to understand. The achilles heel in most MVC programs are bloated, unmaintainable controllers. You still end up with important assumptions being spread hither in yon in user interface code. The fact that it is non-visual interface code makes no difference at all. What you end up is not, fundamentally, different from the typical VB program, but often minus the convenience of tying UI elements to event handlers in the IDE.

There's nothing wrong with the MVC pattern, but there is cargo cult that has grown up around it, spurred by the impedance mismatch between browser presentations and server side processing.

You can't force people to do good design by making what the produce resemble a good design.

With respect to XML and other data representations of views, I've dabbled in them, and have not been that impressed. Consider isomorphic view represenations, one in Java and one in XML. Once you've gone through the effort of separating out your contol logic, there isn't much to choose between them. Sure, the XMl is probably language independent. But the Java is trivial, which helps make your code independent of the framework.

IntelliJ

IntelliJ's designer does exactly that. I saves the UI code in XML files and you only need to code the specific business logic in a seperate class. The designer itself is quite nice as well.

TrollTech's Jambi does this quite nicely

It can be used opensource (GPL) as well as commercially. Here is the link to the tech preview. [trolltech.com]

I have to say, I'm pretty impressed so far.

Who builds GUI's anymore....

Every single application I build these days, either for business or for personal use are based on a web UI. Java has incredible MVC frameworks for building web based applications from Struts, Spring, Tapestry, etc... Honestly, if someone is building a Swing based GUI, I'd have to ask: WHY?

Serializing GUIs is difficult?

I've always wondered why simply serializing a GUI wasn't used more in Java. Perhaps because Swing is so easy to use. Most java programmers I've known in the past shunned any type of GUI development tool in favor of hand-coding swing because it's so much more straight forward.

Also, it's difficult to get reuse out of a GUI editing tool, but very easy to get it by hand-coding. I generally write factory-type code that handles generating menus, buttons and linked Actions together, in a GUI tool you will often end up having to deal with each of these separately.

Much of the GUI code I've had to deal with is in the form of Properties sheets (large number of controls in predictable patterns). You absolutely should never generate this kind of GUI--or hand code the gui itself for that matter. The entire GUI should be generated from data files.

So in the past, RAD tools for swing were used by more amateur less professional users, and the amateur users are going to feel much more comfortable with generated code. Now that the tools are coming up to the point where professionals are starting to use them, I think we'll see a lot more cases of "Serialize out a finished screen at design time" and "Serialize it back in at runtime". (This was in some of SUN's original Java tools if I remember correctly).

ResEdit

it was in 1984 that we already had ResEdit [wikipedia.org] which abstracted the whole GUI from the code -- it did such a good job, that end users could open a shipping application executable, and go in and change bitmaps, menu keyboard shortcuts, dialogue texts, and sounds -- so long as they kept the same resource ID, the app would keep on working.

this system was eminently useful in getting mac applications translated into languages other than english, as any user could open the shipping application with resedit, start translating strings, save a copy of the resource, and start shipping a translated version. if the translated text was longer, and wouldn't fit in the dialogue box -- no problem, you could alter the window dimensions right there, and since the ID of the dialogue box was still the same, everything still worked.

brilliant, that's how good it was in 1984... then came windows, and we lost all that. some of it survived in the NeXT OS, which carried over the 'Interface Builder' paradigm to unix. this is ultimately the source of application frameworks, and the nested folder structure of an .app in OSX, and its a really nice system once you work with it -- it also lets people responsible for layout to do so without having to bug the programmers. abstracting the GUI from the code like this lets the programmers concentrate on coding, and helps the GUI guys get the tools to make things right from the user perspective.

best regards,
j.

Don't use GUI builders

GUI builders have been around for as long PHB's have wanted to insert themselves into the development process to speed up development. Don't use them. GUI builders relieve the programmer of the easiest, least demanding part of the development process - widget creation and layout. They add overhead and obscure GUI API's. They offer little to better organize interface callbacks into a nicely designed program. In fact the combination of generated and custom code will leave the next guy who has to maintain your program to wonder what you were thinking.

Standard answer: XUL

Why not to use Mozilla XUL instead? There are many proficient pure-Java implementations of XUL [sourceforge.net], including tiny Thinlet [sourceforge.net].

Nice

I'm not sure why Java GUI's being behind the curve and difficult to work with is news. Anyone who has actually used the word 'Gridbag' knows that Java GUI development is a process somewhat akin to Chinese water torture.

having trouble digesting this...

Neither of which promote good MVC separation. In fact they tend to encourage violations unless you are a very disciplined coder.

I don't mean to sound all high and mighty, but if you aren't a disciplined coder, then you're not very serious anyway. You can pre-plan the MVC design to your hearts content, but it takes discipline to stay within the boundaries of the original design. Especially since if you don't then you create one of the worst anti-patterns ever, making you wish you'd just written one monolithic chunk of procedural code because bugs/changes would be doable.

Qt Designer is free

If you use Qt for your interface, their GUI builder is pretty good. And it's free. And it generates C++ that you can inspect, modify and understand.

What good resource based GUIs are there?

So what good resource based GUI builders are there for Java? This is the one thing I have been hunting for, after having developed for the Mac and Windows. I can't stand code generators, since the code is usually large and ugly, and usually require some hand tweaking because the code generation has limitations. I once saw a solution that was written to use XML for the resources, but it ended up almost being as large and monstrous as the Java code it was meant to be replacing.

Maybe using Microsoft's GUI XML format could be a solution? Quite honestly I really think a JSR to make a standard Java GUI resource format would go a long way.

Messy and brittle? What is he talking about?

Java already has external XML GUI description files. They are the .form files generated by Matisse. Matisse lets me drag and drop together a GUI just like any other drag and drop program. It's not brittle; it's rock-solid, fast, and it makes the best-looking forms I've ever seen. At this point I would prefer to build a Swing app over a Web app, because Matisse makes the Swing app so much easier to build and make it look good.

The one problem with Swing is it is capable of doing too much, which makes some of the simple stuff more complicated than it should be. But I can do any kind of visual effect I want to do. Spend a week or two using Matisse and then decide what you think about Swing.

If you haven't used Interface Builder

If you haven't used Interface Builder (IB), then you are really missing out. Many people have a difficult time wrapping their brain around the concepts of Interface Builder, but I assure you it is across the board the best GUI builder paradigm yet invented. For a very brief introduction to its concepts, see Hold Me, Use Me, Free Me http://www.stepwise.com/Articles/Technical/HoldMe. html [stepwise.com].

In fact, IB should have been named "Object Connector" because it is not a "builder" at all. All IB does is let you instantiate objects, specify their initial state, and define connections or relationships between the objects. You should note that it is equally applicable to user interface objects and every other kind of object including your own custom classes. The configured objects are serialized to either a binary file or an XML file (your choice). The "Test" mode in IB just serializes and then de-serializes the object graph in memory to produce a fully functional system that you can test.

Although Interface Builder has been available since 1988, it is actively developed by Apple and is in fact free along with the rest of Apple's development tools with Mac OS X. Recent additions to Interface Builder have included Key-Value Observing which eliminates al lot of "controller" code from a system and Data Modeler which automates a lot of "model" code.

Steve Jobs used to state that it doesn't matter whether code is hand written or computer written, every line of code is a potential bug and a source for future maintenance. The only way to radically improve programmer and life-cycle productivity is to radically reduce the amount of new code needed to implement applications. IB is a stellar example of the wisdom oh his words. [This is also a huge win for cultural localization...)

Given the extremely rich frameworks of objects (both GUI and non-GUI) that are available from Cocoa, IB's ability to instantiate objects and form connections and relationships between them without any code is a huge win. If you haven't used this technique, trust me: you don't know what you are missing. You will never want to go back!

IB's down side has always been documenting (for posterity) all of the connections and relationships that are specified in IB. IB is improving on that front with XML file formats and data "entity-relationship" modeling built in. There have also been plug-in palettes that improve documentation generation.

Just as a reminder, unlike most GUI builders, IB works equally well with your custom classes and the framework classes. You can build new "palettes" for you objects to provide slick graphical interaction, but the basic connections and relationships capabilities work with all objects with no special effort.

Apple's IB description: http://developer.apple.com/tools/interfacebuilder. html [apple.com]
There is an excellent but shallow Introduction to Interface Builder at http://developer.apple.com/documentation/Developer Tools/Conceptual/IBTips/IBTips.html [apple.com]

IBM's Rational Application Developer

First a disclaimer that I work for IBM. Similarly, my comments don't necessarily reflect that of my employer, etc, etc, etc...

http://www-306.ibm.com/software/awdtools/developer /application/ [ibm.com]

I use it for all the coding work I do. It has a GUI building tool that only generates Java code. Its much better than the old visual age line of products that required separate files to manage the GUI construction. You can even edit most of the generated code manually without fear of no longer being able to use the GUI builder. It uses (Eclipse [eclipse.org]) as its base platform so other eclipse plugins can be added to the tool. It includes extensive tools for other web related development as well (DB definitions, EJB work, XML, etc...)

Granted, it's listed as ~$2k for 1 license, so its not for everyone, but you'd be hard pressed to find a java/web development function that it doesn't help you with.

Dan

Foam uses XMLEncoder

Foam used XMLEncoder waaay back when Java 1.4 first came out. http://www.computersinmotion.com/ [computersinmotion.com] they have some example videos. It sure is nice to have your panels created in one line of code :-)

The Qt Way

I like the way Qt (v4) Designer does it. The output of Designer is an XML file, and during the build stage uic (ui compiler) generates a form class. This class is not a widget (as it was in v3), but a very minimal class that's only one step away from being a legitimate POD class or struct. All it essentially contains is the form's component widgets as public data members, aand setupUi() function to layout the form in the widget you pass it. It doesn't inherit from anything.

This gives you a lot of flexibility. You can use the UI object directly, as a data member, or through multiple inheritance. You can even load the XML ui file at runtime if you wish, using the QtUiTools library. It also give you a clean OO design, as the UI itself is a stand-alone object.

Re:Proprietary UI Builder

I am then stuck with some libraries I cannot modify or upgrade and a application that will have to then be redone from scratch

If your application has to be redone from scratch because you want to make some UI changes then you probably need to reconsider your career choice or invest some time in learning about patterns and tiered design.

Re:Proprietary UI Builder

That's why its release as open source as well, so you can have all the source yourself should something happen to it. Or the community at large could keep it going.

Re:Well, when they fix all the bugs in BuoyBuilder

If you report some bugs maybe they would get fixed AC. We are quite willing to fix anything that has been reported, but as of yet, nothing has been reported.

Re:"some XML, some proprietary binaries"

A proprietary XML format that happens to be somewhat easier to read than a proprietary binary format is no less proprietary.
Perhaps not in a legal sense, but it's a hell of a lot easier to reverse engineer.

Re:Proprietary UI Builder

No thank you, what happens when they sell a couple of copies then go under. I am then stuck with some libraries I cannot modify or upgrade and a application that will have to then be redone from scratch. I don't care how fancy your wiz bang cool ui generator is, if I do not have the code it is definitely not going into my app.

Right on their home page:

"BuoyBuilder(TM) is released as Open Source under the OSL license. Royalty-free, commercial licenses are available for purchase."

http://buoybuilder.com/DownloadData/BuoyBuilder-sr c-1.1.zip [buoybuilder.com]
 

Re:code-generators

The other poster mentioned internationalisation; this is important when you have HCI experts for each locale designing custom UIs. I really don't understand what you mean when you say:

if you're using a lot of custom components it's more flexible.

The system used by NeXT (and now Apple and GNUstep) in the first RAD tool, was very simple. You create an object graph, and serialise it. In your code, you can create instances of this object graph. This seems to me to be a lot more flexible than having to hard-code the connections.

Re:code-generators

You have never developed an application that needs to be internationalized, obviously.

Different cultures and different languages need items positioned differently. Some languages are read left to right, others right to left, others top to bottom. Some phrases are much longer in some languages than others. All this makes impossible to have an universal layout.

And yet, nearly all Java layouts seem to do exactly that. If you don't believe it, arrange some components into a GridBagLayout with at least two columns and look at the results. Then add a call to applyComponentOrientation( ComponentOrientation.RIGHT_TO_LEFT ) on the window (after all components have been added to it), recompile and look at the results again.