Ben Galbraith's Blog

Successful GUI Building... Today

I'm not surprised to find negative sentiments towards GUI builders of the kind recently voiced by the HackNot blog (and linked by John Reynolds). For a long time, I avoided GUI building in Java, finding it a terribly unpleasant exercise.

Over the past year, I've experienced a very pleasant change in attitude, and whereas last year I would have voiced ambivilance about using GUI tools, today I think you'd be crazy to avoid them.

In my experience, the number one reason why GUI builders hold appeal is that they often lead to an order of magnitude improvement in productivity over handcoding, especially amongst average-level Swing developers. I consider myself above average, and I see improvements in productivity around 2x-10x (perhaps higher) in my own work. I challenge anyone who refutes this to a code off; just check the No Fluff Just Stuff schedule to see when I'm going to be in your area -- or let's do it at JavaOne 2006.

Why such a radical increase? Frankly, I think its fairly obvious, but since HackNot's piece didn't acknowledge it as a factor, just consider that the domain of GUI design is, err, visual, and doing design by writing code either means you've got to get to the point where you can reliably visualize what your layout manager does in your head (emphasis on reliably, folks), or you wind up compiling and executing over and over again doing minor/major tweaking until you finally get it right. That cycle alone seems to indicate how a visual tool can speed the process up. Consider also that Karsten Lentzsch, the Swing community's resident visual expert, recommends that hand-coders layout the GUI on paper before attempting to code it. Again, not hard to see how using the visual tool can lead to a significant productivity improvement by allowing you to skip that step.

By the way, I need to mention that I'm not talking about using a GUI builder to do absolute positioning -- I'm talking about doing layout management with the GUI builder.

I think the negativity voiced by HackNot and others about GUI builders isn't a rejection of the productivity increase of the GUI layout -- I think its too obvious and powerful to refute. I think its really a response to the current way that the tools integrate with Java code. (Though again, anyone who thinks modern tools don't intergate well with layout managers needs to look again.)

The key to success with GUI builders is to eschew code generation. That's a really bad idea for a lot of reasons. The model I've come to favor is using GUI builders to generate a binary representation of the GUI that you load at run-time.

For example, I use a tool to build a GUI panel, save it to a file named "MyForm", and then at run-time I do something like this:

RuntimeForm myForm = loadRuntimeForm("MyForm");
JPanel container = myForm.getContainerPanel();

Using this approach, I don't have to worry about how the GUI builder generates code, how it names variables, etc. Its then easy for me to attach behaviors to this GUI:

JButton myButton = (JButton) myForm.getComponent("myButton");
myButton.addActionListener(...);

The key here is that you name the button "myButton" in your GUI tool (e.g., using the Swing "name" property). This approach also makes reusing common GUI elements easy. If I am working on design and notice that there's some common recurring pattern that can actually yield an ROI if I reuse it I save the reusable component off to a panel and combine it at run-time, in a fashion such as this:

RuntimeForm myForm = loadRuntimeForm("MyForm");
RuntimeForm subpanel = loadRuntimeForm("SomePanel");
JPanel somePanelParent = (JPanel) myForm.getComponent("somePanelParent");
somePanelParent.add(subpanel.getContainerPanel());

Of course, this process can be made much easier by adding some conventions / helper methods to your framework, but that's another story. (By the way, "RuntimeForm" is an abstraction layer that lets you use any GUI builder at any time, or XUL tools for that manner -- they all generate the same product at run-time: a Swing component hierarchy.)

HackNot mentions having to layout components differently depending on locale as an argument against GUI builders. This requirement can be pretty easily generalized into a Swing widget, or it can be realized as code that manipulates your loaded panel, whatever your pleasure. This seems a pretty weak case against GUI builders to me.

So to summarize, using modern GUI builders and the right techniques, you aren't stuck with absolute positioning, you can reuse GUI patterns easily, you get separation of concerns for free, you can do i18n easily (every decent GUI builder supports this, but that doesn't matter -- you can do it at run-time without tool support), and you get a huge increase in productivity.

Before I wrap up -- which GUI builder do I use? There are a number of high-quality GUI builders on the market today. My favorite such tool is JFormDesigner, created by one-man-show Karl Tauber; its killer feature is tight integration with JGoodies FormLayout. Of course, when Matisse is ready, it is looking like it will be the one to beat.

Stop worrying and learn to love GUI builders. Their time has come -- but just say "no" to code generation.

Comments

• Interesting approach! I haven't seen people directly address how to isolate the GUI-builder generated code from application code. Most people just generate a GUI panel, then insert their own application code right into the builder-generated code. That, in my opinion, leads to a lot of trouble, not the least of which is tool lock-in.

  You have successfully convinced me to give GUI builders a try again.

  Posted by: burke_e on August 01, 2005 at 06:04 AM

• Ben,
  I'm going to mildly disagree with you with respect to the loathsome topic of code generation...

  From the perspective of long-term maintenance in an environment where the average programmer changes jobs every two years, it's very helpful to have an environment that lets the "new guy" start at a screen and drill down into the code.

  I perceive a huge "maintainability" gain when an IDE allows me to navigate from a component on a screen to the underlying actions (code) that governs the component's behaviors.With the loadRuntimeForm approach, it's a bit more difficult to get from the "picture" or the screen to "what the screen does".

  
  --John

  Posted by: johnreynolds on August 01, 2005 at 06:08 AM

• 
  johnreynolds: I don't disagree with you, but I think that approach conflicts with the spirit of Java. In Microsoft-land, everyone uses Visual Studio, so coupling your code to that tool makes a lot of sense, and you get nice features like tight integration with the visual builder.

  
  In Java-land, we tend to value decoupling the development environment from the project. I think its common to see teams where folks use emacs, IDEA, and Eclipse. We enjoy our freedom. (Or, to be honest, some folks might say that because our bosses have chosen Java we're stuck with subpar tools that force us to assemble development environments ourselves and the constant leapfrogging of tool vendors forces us to make sure we're able to switch without too much pain -- I wouldn't say that, but I hear that sentiment often).

  
  Because of that, I prefer approaches that allow me to be very productive while decoupled from specific tools. Thus, I really like the approach that lets me use any GUI tool, though I do loose tight integration with any one tool. In practice, it works out really well, though as you mention, the guy I hire off the street will need a few minutes training to figure it all out.

  
  It wouldn't be hard to create a standard that allowed a decoupled GUI tool to integrate with your codebase. Someone would just need to formalize how widgets in the GUI are bound to actions in the code. I may talk to Karl to see if he can support my own scheme in his tool. That would deliver the experience you describe.
  

  Posted by: javaben on August 01, 2005 at 06:29 AM

• "It wouldn't be hard to create a standard that allowed a decoupled GUI tool to integrate with your codebase. Someone would just need to formalize how widgets in the GUI are bound to actions in the code. I may talk to Karl to see if he can support my own scheme in his tool. That would deliver the experience you describe."

  That would be great Ben... but make sure that making such a suggestion doesn't get you in trouble with the "spirit of Java" police ;-)

  I think we can have our cake and eat it too. We can have component frameworks, both desktop and web, that enable powerful tools without locking the user into specific tools.
  For example, the Matisse project is coming up with some pretty nifty tools for specifying screen layout... but it's not within their current scope to expose the layout hints that NetBeans will use in a format that could be imported by Eclipse (or any other tool).

  I love tools, but I hate being locked into a specific tool.

  --John

  Posted by: johnreynolds on August 01, 2005 at 06:49 AM

• 
  johnreynolds: Sounds like we're on exactly the same page ;-).

  I love tools, but I hate being locked into a specific tool.

  Yep. E.g., NetBeans will include some interesting mechanism for locking down the code that Matisse generates and integrating that into your code, but I'm absolutely not interested in tying myself to NB.

  
  My current approach keeps you nicely decoupled from your GUI builder tool and yet makes you able to tightly integrate what is generated with the rest of your backend code.

  
  I interpreted your earlier comment as a bit of a dig against the approach because you don't have the ability to click on a widget and be taken to the action code behind it (or the model code, etc.) -- so just pointed out that it would actually be easy to implement that level of functionality with a small standard, and I think the best way to start that would be to have a proof-of-concept implementation with a particular tool that is still abstracted above that tool and then push that into other tools, eventually creating a JSR to document what the community is already doing.
  

  Posted by: javaben on August 01, 2005 at 08:27 AM

• Thanks Ben for this bit of sanity among all those really weird posts about GUI builders :)

  Posted by: gfx on August 01, 2005 at 10:57 AM

• The main problem I have with GUI builders apart from the apalling code most create and the lack of flexibility they usually suffer from is the fact that they make people skip learning the language in favour of learning the tool.
  While less important in a professional environment, students tend to be dazzled by shiny stones which leads them to GUI builders. They then become incapable of coding anything by hand, and are completely stuck when put in an environment where that exact same tool isn't available.

  And users SHOULD be able to modify the generated code. There's no tool that can let you generate every possible behaviour (simply because the tool creator can't be expected to think of every possible use something might be put to in the real world), so handcoding and modification of generated code will always be needed.
  If you lock down the generated code completely and make it impossible to modify, you loose that flexibility.
  If you don't lock it down, your tool'd better be highly flexible in reverse engineering the modifications made by hand (rather than just throwing them all away as many tools do now) and create very good code itself (which many tools now do not).
  

  Posted by: jwenting on August 02, 2005 at 02:25 AM

• abeille Forms Designer follows the same approach, uses JGoodies FormLayout and is now open source. I've been using it for the past year to build quick analysis and simulation tools for my PhD. The only disadvantage is that the GUI itself is locked inside a serialised .jfrm file. However, for my work, this isn't a problem and there are efforts underway to serialise to XML files.

  I've used GUI designers since I first had one available (Visual Cafe 2? Certainly in various JBuilder and Netbeans flavours). However, before Abeille Forms Designer, I've usually defaulted back to manual hacking GridBayLayouts or FormLayouts. That was until I started using Abeille. Now, as long as the names of each component remains the same, I can change the GUI without changing my application code, do lots of quick rapid prototyping, etc. Personally I think this external representation with named components is the way to go.

  Anyone who thinks that Java code is the best representation of layout constraints just doesn't have their head on straight. It's even worse if you think that the best way to manipulate that representation is manually via the keyboard! The reason we've all been hand-coding is because of the fear of tool lock-in or file corruption from a bug in the tool. But we shouldn't blind ourselves into thinking Java code is the panacea for GUI representations. I would prefer if Netbeans kept more of the GUI stuff out of the Java code (like Abeille) and in an open file format (perhaps XML), which can be ported between different tools. But then, I've always like my bacon with aeronautical aspirations!

  Posted by: hopeless on August 02, 2005 at 05:08 AM

• 
  I think the problem with GUI builders is that people use the to create behaviour when they should be used just to create layout. I see no advantage in having a of of widget.setProperty() lines and editting them by hand, it's far better to change then using the gui builder and its properties window.

  The aproach you sugested has already been used for many years in the Linux Desktop Gnome. Their GUI Builder, Glade, can generate code but the prefered way is to save the layout to a XML file. You can then use the same XML file to create GTK widgets on C, Java, Python, Perl, Pascal or any other language availabe. If you visit the JavaGnome Project (java-gnome.sf.net) and scan though their wiki you'll see many nice examples on how this approach works fine and what could be the standard Java API.

  Of course there are times when it makes more sense to create components programatically, but this poses no problem. Reusing layouts is also easy (you just reuse a subtree of the XML design). The real problem is when people want to double-click a button and edit the ActionPerformed code and other events.

  Glade provides no feature for that. It simply let's you register the name of a method or function associated with an event. At runtime it binds the event, when you realise the XML design. So developers can use Glade alongside Emacs, Anjuta, KDevelop and even Eclipse (there are plug-ins that invoke Glade from Eclipse menus or from an glade file inside your eclipse project).

  So the approach is very well tested and proved to work. I guess most XUL tools work the same way, and I've heard about many Swing and SWT gui builders that works like that. It's just a matter of standardizing the XML file format, the API that povides run-time access to the widgets, and the way events are bound, so you get no tool/vendor lock-in.

  I really can't understand why Matisse (and, for that matter, Eclipse VE) aren't following this approach, and why there isn't a JSR definding the standard. :-(

  Posted by: flozano on August 02, 2005 at 07:43 AM

• 
  jwenting: I don't consider myself a better developer for having learned how to do GridBagLayout by hand. Frankly, I just want those hours back. There's a middle ground to the tool monkey vs. code grinder argument. For example, I don't know how to generate Java bytecode by hand, though I might be able to do it better than javac. In fact, there are a number of features supported by bytecode that the Java syntax just doesn't give you. But, frankly, I value my own time way too much to waste any time figuring out how to write it by hand. I suggest GUI layout may fit into the same category. I just don't see the value of teaching someone to do it by hand over a tool.

  
  However, you still do learn how the layout manager works in principle, so if you had to do it by hand, it wouldn't be much of a stretch.

  
  hopeless: JFormDesigner actually serializes to the JavaBeans serialization mechanism's XML grammar; I really like that approach, though I haven't thought through the versioning issues.

  
  flozano: Add OS X and NextStep to your list of predecessors that use this approach; I certainly agree that its not revolutionary -- though for many Java developers, it can be quite a revelation.

  
  RE: Standard XML grammar. There's been some talk of this around the Swing team; I think they are working towards this in the SwingLabs effort. That would certainly be the ideal scenario; a XUL grammar that is both hand-coding friendly and up to the needs of individual tools as a standard serialization format.
  

  Posted by: javaben on August 02, 2005 at 08:56 AM

• One of my biggest aversions to GUI builders is all the mousing around. It's slow, and it leads to CPS. I am much more efficient with the keyboard.

  
  But I also like clean code, no vendor lock-in, and all that other good stuff that's been mentioned.

  
  As for sketching out your forms on paper first, my starting point is often screenshots generated by requirements people. Throw a grid over that, and code it in TableLayout. Otherwise, I can visualize simple layouts in my head, and sketch complex ones on paper. Much faster than putzing around with the mouse the whole time.

  
  But everyone probably needs to work within his own constraints (no GUI builders allowed or NetBeans GUI builder mandated or whatever) and/or find what works best for them. 13 years of trying GUI builders including Matisse, and I still prefer hand-coding by a wide margin.

  
  I'm almost tempted to take you up on your challenge, Ben. For the fun of it, that is. I don't think it would prove anything, but it would be fun!

  Posted by: detorres on August 02, 2005 at 09:11 AM

• I almost never code GUI by hand, but on the other side, I like the control that I have using a GUI builder that generates code and lets me modify it. I only know two of them, VE and Jigloo, both for Eclipse (I use the latter).

  Defining the UI in XML or binary form worries me in a few ways:
  * reduced productivity 1: adding listeners by hand is slower than having them generated;
  * reduced productivity 2: I have to generate the code that extracts the components I need to manipulate by hand. If the tools generates a skeleton, it's anyway my task to keep it in synch with the GUI when the inevitable change requests come down
  * refactoring loss: I cannot change the components names in both the UI and the code that manipulates it in one shot.
  * lock in: none of the tools you cited allows to modify the UI if you don't have the tool itself. Which means, I have to buy a license for every developer (at least at my work site, where every developer must be able to cover every topic, from database to o/r mapping to jsf to swing).

  Both first code creation and heavy manipulation/refactoring seems to be worsened by the abeille/jformdesigner approach. With Jigloo I can manipulate generated code, and there is no full lock in since it's still pure java code. When I don't need to manipulate the generated code, I just usually ignore it...

  Posted by: aaime on August 02, 2005 at 10:05 AM

• Sadly it looks like you won't be in germany any time soon, so I can't beat you in that challenge - and I'm quite sure I would.
  I wouldn't consider myself an "average" or "above average" developer. I'm 19, I finished school a few months ago, but there's no big deal in imagine how the written code will look like. LayoutManagers are quite verbose, aren't they? And yes: I can say I'm able to reliable imagine a GUI - except some kind of inexperienced developer wrote the code... like using GridBagLayout without utility - but then: who does that? Ok... I saw it in "Swing Hacks", but that doesn't count.
  Yeah... maybe I could have said it more kindly... so: Sorry if I got to aggressive... just isn't my day.

  Posted by: pago on August 02, 2005 at 10:46 AM

• 
  aaime: Hey, thanks for the feedback. Swing Designer is another Eclipse plug-in. As an aside, one of the big problems I have wth Swing designers on Eclipse is that they don't work on the Mac, and may never (issue with threading on that platform). But I digress.

  
  Regarding your points:

  
  1. Adding listeners by hand. What do you mean "by hand"?

  
  2. Generate code that extracts... Actually, you don't need to do this. I didn't go into my framework speech too much, but in my apps with this approach, I just do something like:
  registerListeners(form, new NewWidgetAction(), new QuitAction(), ...)
  and the framework seams it all up, using name-based binding. If you follow a package convention, you don't even have to do that.

  
  Of course, if intelligent defaults isn't your bag, you can do this:
  registerListener(componentName, new ListenerClass());
  which is also fairly free of tedium. The boilerplate code can be removed from any process.

  
  If for some reason you want to do the listener stuff visually, you could create a "Listener" widget that allows you to define the bindings at design-time and is aware of the code in your project. This approach to non-visual configuration was/is common in the Microsoft world.

  
  3. Refactoring. Actually, because JFormDesigner creates XML, refactoring works rather well in my editor (IDEA).

  
  4. RE: having to buy the tool. Some people make a case that any commercial tool is unpalatable, regardless of its value add or its price. I think that's a tad extreme. JFormDesigner is around $150. Will it save your developers 3-6 hours of time amortized over a year? If they spend much time doing GUI designer, I think the answer is an emphatic "YES!" Commercial software is not evil.

  
  I have a real problem with trying to own and maintain the code a visual designer creates. That creates the horror stories of the kind HackNot described. But, could be that I need to familiarize myself with the latest tools -- perhaps they generate great code.

  
  In any event, I didn't go into it in the posting beyond a quick phrase, but enforcing the separation of concerns (GUI layout and business logic) is a huge value add for me. So many projects have these 10,000 line class files that contain all the concerns mashed together. In these scenarios, the difficulty of maintaining the code is a factor, but more serious is the barrier to reuse that it creates. By separating the GUI layout concern with the behaviorial concern (and further, the data population concern, but that's a framework story again...) you can increase opportunities for reuse and significantly ease maintenance.

  
  RE: vendor lock-in. JFormDesigner actually can create source code, so you move away from the tool, you could create the code for the UI. You could also just rely on source code generation, and use the same techniques I illustrate above, and always have the source code available to you. So, you can have your cake and eat it too.

  
  So in summary, I think your first two points are no-issues (but I would like to understand further what you meant by #1) that are solved by writing some simple integration code, your third point isn't a factor when your GUI serialization format is XML, and your fourth point is penny-wise but pound-poor. Am I off-base?

  
  pago: Sorry that you're having a bad day. Fortunately, I may be in Europe up to three times this Fall / Winter, so let's get together and make the competition happen. This isn't about programming bravura, its about showing that a GUI builder makes layout *so easy* that by its nature its just so much faster than doing layout by hand. But by all means, happy to demonstrate that in person.

  
  My own comparison from rendering a UI with FormLayout or Packer versus the visual designer demonstrates that I'm much faster with the GUI builder than typing it out, even when I am copying an existing GUI literally. The factors are hugely in favor of the UI when you need to experiment or iterate designs -- which happens quite often.

  
  RE: GridBag without utlities. Err, dude? Sadly, this is common in the workplace.
  

  Posted by: javaben on August 02, 2005 at 12:44 PM

• humm... using Listeners instead of Actions to add functionality to the form buttons ?

  It seems out of patterns....

  Posted by: felipegaucho on August 02, 2005 at 12:48 PM

• Given the vastly different ideals, goals, experience, and restrictions in various GUI projects, there's more than enough room for GUI builders and hand-coding or a mix of both. The wild differences between experienced/inexperienced programmers, internal corportate apps/off-the-shelf software products/open-source apps, and time/budget/team size mean that various approaches are going to appeal to different persons/groups.

  GUI builders are not evil. Vendor lock-in is not evil (especially when the product is FREE!). Code generation is not evil. There's a time and place for each and they can be used quite successfully. Should any/all of them be used in every project? No way! Have people been burned in the past by using them? Absolutely! But that can be for a variety of reasons, some controllable, some not (experience, training, buggy tool, not enough time on the 'learning curve', etc.).

  When you take the time to investigate various tools and learn them, you decide which ones are good and put them in your toolbox. Hand-crafted software built entirely from the keyboard can be a thing of beauty and wonder to the beholder (er, coder) and some others, but it's not the same to everyone. Some tools can produce great results very quickly. But the hand-crafting coders and the tool-users frequently don't have a very open mind about the other side of the fence and can't understand why anyone would spend time there. Jump over the fence once in a while! For both types it can be a worthwhile experience, but it can't be done in just an hour or two, so plan to be there for awhile.

  Posted by: gerryg on August 02, 2005 at 01:03 PM

• Ben,
  "by hand" I mean hand coding instead of having an anonymous inner class generated for you.

  As far as actions are concerned, I use them only to build related components (button, menu and toolbar), but never in my dialog button handlers... I don't see the added value, since they usually need a reference to the main component as well to pop up messages, other dialogs, modify component states.
  Besides, I usually have other listeners as well, click over tables, selection listeners, how do you handle them with Action subclasses?

  As far the money is concerned, that's not my decision to take. If I go to the boss and tell him to spend 600$ for each developer to by IDEA and JFormDesigner I may find myself looking for another job, probably not java oriented because here in Italy .NET and VB6 are far more popular.

  As far code sizes are concerned, I rarely find myself writing classes with more than 500 loc and having the gui building code included into them.

  I'd like to have a look at your framework (you called it a "cliend side container" once), there are for sure many things to learn.

  Posted by: aaime on August 02, 2005 at 01:41 PM

• What on earth is wrong with hand-coding GridBagLayouts?

  I kept hearing people saying how hard it was to use, but when I actually learned it, I was pleasantly surprised at how simple it was to use. It only takes ten or twenty minutes to learn, and it's certainly not any harder than, say, laying out a web page in HTML.

  It's more verbose than most of the other layouts I've used, though probably not as bad as FormLayout--who in their right mind wants to learn a new language used in string literals inside the code just to lay out components?

  Right now I use a combination of BorderLayout and GridBagLayouts to set up almost all my GUIs. It's a piece of cake.

  Posted by: afishionado on August 02, 2005 at 02:15 PM

• Code generation is bad. Back in my C/Windows programming days we had RC files. Nobody complained about them and you weren't locked to any tool (just windows :) ).
  Code generation is horrible.. it muddles up the code. I like your example, my only objection is the use of a binary format tied to a single tool. It's much better to have a file in some declarative text format that is loaded at runtime or compiled to a binary that is loaded at runtime. That way hand tweaks are still possible and you can diff in your source control.
  Layout of an initial page is declarative.. so there's no reason to have a bunch of procedural code expressing it. JDNC's XML is promissing in this regard.

  Posted by: dog on August 02, 2005 at 02:59 PM

• 
  felipegaucho: when I say "listener", I mean code that listens for events, including Actions, which are built on top of ActionListener. I actually take the Action mechanism and extend it to support non-ActionListener events, such as selected items in a table. I use a binding similiar to SWT's untyped event listener model, where you can specify the type of event that is mapped to the Action. I do this because right now the framework I use provides thread handling for Actions; I haven't generalized it to the level of all Listeners -- though perhaps I should.

  
  gerryg: That's absolutely right, and the point I make when I speak on this stuff is that Swing applications should support all approaches: hand-coding, XUL layouts, GUI builders, etc. I like the notion of a Form that separates the (1) creating and laying out components, (2) attaching listeners, and (3) populating data into separate concerns, and from form to form you can choose different implementations.

  
  aaime: Interesting. I haven't had much expense here; when something's material, I factor it out into a reusable Action, otherwise, IntelliJ IDEA does a good job of writing the Listener template stuff for you.

  
  Yeah, out of the box Actions don't give you value if you don't share them, and in fact, the JavaDoc recommends against them unless they are shared. I extend them to do other things, including handling threading, validation, data binding, etc. But what I said wasn't specific to Action instances; it was more related to registering listeners in general.

  
  As far spending money on tools, it's all about making the ROI case. I'm much faster with IDEA and JFormDesigner, and in general, commercial software can save me a ton of time. If the equation works -- spend $100 to save $1000 -- then not buying the tool is really foolish. If your boss doesn't listen to reason, you may have larger problems than not getting the tools you want. ;-)

  
  afishionado: Having spent years doing table layouts in web pages, the issue is not that GridBagLayout's model is somehow too confusing for developers to grasp. The issue is (a) doing things faster and (b) in a maintainable fashion. I contend that JGoodies FormLayout coupled with a GUI builder can make you much more productive than GridBagLayout by hand. I think if you gave it a try, there's a good chance you'd agree.

  
  You may be interested to know that in my experience, your view is in the extreme minority; most developers *hate* coding with GridBagLayout.

  
  dog: I agree. :-)
  

  Posted by: javaben on August 02, 2005 at 03:56 PM

• I haven't looked at any of the GUI builders you talked about. They sound similar to what happens on the Mac, where it serializes the UI from the builder and then unserialises it on startup.
  The Java GUI builders I have seen however are awful. Visual Basic's one great strength was its fast and easy GUI generation (well, that and nice help doco up to but not after version 5). Being able to slap a button down and then double click on the button and have it take you straight to the event handling code... incredibly productive.
  My last really major swing project we'd inherited from a guy who didn't know java before he started it. He'd gotten an incredibly long way just on the strength of the JBuilder gui builder, but he'd done some bad things (such as writing his own field polling thread to see if the contents of the textboxes had changed instead of using events). So I went in to clean it up. Here's what I did:
  Split off all of the major panels into their own classes (classic divide and conquer stuff).
  Normalised layouts and constants to allow for reuse.
  Wrote a bunch of components to encapsulate our look and feel. Eg our text fields all had labels above them with particular font colours and styles.
  The end result was that I could make certain kinds of sweeping changes in code much much much faster than even the fastest mouser could ever do in a gui builder.
  There were some drawbacks. Firstly - fairly quickly into the process JBuilder stopped being able to show our panels in its designer. This meant that only one developer could make changes, that is the one who knew swing fairly well (ie me). This meant I had to do any new screens and panels and we weren't able to delegate that to the junior developers. Secondly that when you can perform miracles people come to expect them. :D Thirdly there was a proliferation (nay a veritable explosion) of small ui related classes, which facilitated reuse and reduced overall code size, but would make it harder for another developer to pick it up and run with it.
  In addition to 'code reuse' (which is a bit abstract as far as advantages go)... the main advantages of this approach were firstly - kicking butt and taking names :D , secondly coming in on time and under budget, and thirdly eliminating a whole slew of obscure timing related errors (which as it turned out were not happening in the field anyways, but I'm happier knowing they're gone even if the users wouldn't see them).
  OTOH one of the things I'll never miss about the VB gui builder is not being able to open up the code and look under the hood to see what it is doing. Whereas the problem with java guis is the opposite - that you are *required* to open up the hood and tinker.

  Posted by: rickcarson on August 02, 2005 at 09:07 PM

• Which sums up my case against GUI builders pretty well...
  When used to "learn" programming GUIs they tend to actually prevent learning. The student thinks he now knows how to program but in reality all he knows is how to use his/her specific tool. When that tool fails to deliver (either because the tool doesn't understand what it's being fed as in this case or because the tool is inadequate (doesn't support what needs to be done), they fall by the wayside and the one or two (if you're lucky to have them) people who DO know how to code instead of click and drag get a work overload (because management doesn't see a problem, after all there's X man hours available and those people all have the required skills according to their resumes).
  Just making sure that all code is generated directly into binaries that can't be changed by anyone except the GUI builder isn't the solution. In fact it's setting up for disaster.'

  Posted by: jwenting on August 02, 2005 at 10:57 PM

• 
  jwenting: Just to follow up -- JFormDesigner uses JDK 1.4 XML serialization mechanism to create its "binary" files. I treat them as binary, but they are actually transparent. And, as I mentioned in other comments, it can also generate source code. So... lock-in isn't a disaster scenario with this tool, nor with others that are used in a similiar fashion.

  
  We'll just have to agree to disagree on your assertion that developers should have to become experts doing it the manual way before they can use tools. I disagree so strongly with this line of reasoning that I will probably blog on it some time. ;-)
  

  Posted by: javaben on August 02, 2005 at 11:13 PM

• Besides the obvious differences, there are common points. Like you I have thread offloading management (but it's based on runnables instead of actions), centralized exception handling, glass pane management, single frame modal dialogs, dialog utilities (I have around 50 dialogs in my last app yet I don't have a single JDialog subclass in my code) and a few other things.

  It would be nice to set up an open source project to open up those efforts, they are often neglected in other open source projects I've seen (JDNC, in particular).

  Posted by: aaime on August 03, 2005 at 12:32 AM

• Sounds fine. Just let me know when you're there - and where.
  I've some experience with GUI-builders and I never noticed any speed-up. Instead, they've effectifly slowed me down. I never was more unproductive. I've been unable to find the property I had to change, I had to find the right place to dock the component, I had to... oh well... just let me say it again: There was absolutly no improvement. Might be 'cause I'm not the kind of guy that uses a GUI-builder. I would also say that using a good editor HTML is way faster to be written by hand than with a WYSIWYG-tool like Dreamweaver. It just doesn't make it easier for me. I described my experience with GUI-builders on last Javalobbys discussion about it.
  On the GridBagLayout-thing: Well... if it is common it doesn't mean I have to agree with it, right? I wrote such an utility, it spans 600 lines (including documentation) and makes using GridBagLayout as easy as FormLayout. It took me something around half an hour to write it and has saved me hours of maintainance. And if I hadn't done that one, there would have been Packer or I could have used FormLayout directly.

  Posted by: pago on August 03, 2005 at 12:51 AM

• I have really enjoyed the comments prompted by Ben's blog, and it set me off down a different path...
  Would you oppose generated code if the generated code made it easier to maintain your code over the long term? (presumably the generated code would follow conventions to insure that it would work with monitoring/profiling/debug tools).

  The results of this musing are captured in my blog entry: Longing for an Integrated Maintenance Environment.

  --John

  Posted by: johnreynolds on August 03, 2005 at 10:46 AM

• First off, Gregg blogs Project Matisse: Some Comments. Of particular interest from it is:

  
  This is a link to the Hacknot article on why GUI builders should be avoided. The article is very well written. I do not agree with some of its conclusions, but I admire the quality of the prose. One of its main arguments is that GUI builders lock you in to a tool. That can be true but it should be pointed out that with the NetBeans form editor you have complete control over that lock-in. The tool creates two files: a .java source file and a .form file with metadata. If you decide you are tired of the lock-in just delete the .form file. The remaining .java file is yours to keep and do with as you will using NetBeans or any other tool. After all, it's just Java code. I have used NetBeans this way when creating applications. In those situations I am essentially using the form editor as a visual "keystroke macro" so that I don't have to type in all that code.

  
  So NetBeans doesn't really have vendor lock-in, but it's kind of like if you unlock it you can't lock it back in again easily. The main idea is let the tool do it's job and resist the urge to muck around with the parts it's finicky about unless you absolutely have to or have decided or been forced to use a different tool.

  John, I'm totally with you:

  
  Maintainability may force you to follow rigid coding conventions. It may limit your choice of frameworks and libraries. You might have to settle for the status quo instead of experimenting with the bleeding edge. But in the real world maintainable code is better code. Losing your coding freedom hurts, but sometimes you just do what you gotta do to keep things running smoothly.

  
  When maintaining or developing an app, I'd rather work with a GUI builder where I could just drag a few things over to where the customer really wants them (possibly with the customer there) than guess how many pixels over I should shift them. Even if I'm using an older tool and have to keep it around while I use a newer one for new stuff, fine, but having to patch code (or resource files) by hand with guess work would just slow me down and possibly introduce bugs.

  I'm also in the camp where having a UI designer and not a programmer come up with an interface is a Good Thing (TM), and letting them go off with a GUI builder tool and then wiring it up when they're done will mean that it's done right. At least having templates to work from helps a lot. Or having a working, tested model and persistence layer and letting the UI designer wire it up as they do their magic is good, too. We all like doing GUIs, but some people really are better than others at it.

  Posted by: gerryg on August 03, 2005 at 05:00 PM

• Without stirring things up too much, I've used my Packer (http://packer.dev.java.net) class since 1995/1996 for all of my layout needs. I've hand coded my GUIs and done all of the anonymous classes by hand. What I find is that I can copy and paste listeners of the same type when I am creating listeners for buttons, menuitems etc. So, I don't have to type a lot of that stuff repeatedly.

  The design of Packer was intended to minimize typing and lines of code to a minimum so that I could be more productive and less error prone in creating UIs. I used to have a great GUI builder that I wrote on the Amiga that essentially used a rectangular layout with the typical anchor, fill and span capabilities that gridbag, tcl/tk-packer and others use. What I found with that builder was that I really couldn't save much time because I had to switch through too many contexts between editing source, compiling and GUI design.

  The IDEs that are around today are far better at helping bridge this gap, but noone, that I've found, has bit the bullet and said we'll only do rectangular layout with gridbag, and make it easy. Instead, we have the use of the layouts that have positional relationships like top, right, left, bottom, flow layout, box layout and similar where you just can't create a nice layout.

  I've give lots of thoughts over the years to creating a new builder, but I want it to live inside of an IDE, and I haven't found an opensource IDE yet that I can stand to use for serious work.

  I might have to finally finish my Java version of Kawa and integrate it into that...
  

  Posted by: greggwon on August 07, 2005 at 10:32 PM

• 
  Thanks very much for all the comments. Let me respond to the latest few.

  
  aaime: I started out enhancing Runnable to do what I wanted, but I wound up finding that having users even think about threads was more than I wanted them to do, so I retreated to Action, which users have to create anyway. I could have enhanced Listeners, but that seemed like quite a bit o' work.

  
  I would really love to see SwingLabs gradually take on most of this stuff, and I think they are certainly excited to provide value in this space. We should chat with Richard, Hans, Amy, etc. and see where efforts like ours could plug in.

  
  pago: Heh, you're on dude. I'll be at JavaPolis in Antwerp, Euro OSCON in Amsterdam (though I may pull out of that one), and possibly Denmark in January.

  
  johnreynolds: One point I may not have emphasized WRT code generation is my strong desire to maintain separation of concerns. I don't want business logic in the UI classes, and if users have the ability to go in and add inner classes that contain biz logic, ugh. I like attaching the listeners in a separate step.

  
  If the GUI is not a "binary artifact" but Java source code, works for me, as long as its treated as read only.

  
  gerryg: Just want to emphasize, as I've done before, that JFormDesigner also allows for that approach (generating XML or Java code). I think we're in total agreement.

  
  greggwon: You really ought to check out JFormDesigner's support for JGoodies' FormLayout -- seriously. First, it has excellent support for grid-based layout. Second, FormLayout has a number of important features that GridBag doesn't. Third, you could reuse listeners so easily with an approach like the one I've outlined. Forth, you also stay focused on a single concern (GUI building) and not other concerns, such as looking up JavaDocs to see what the values are for a particular constant, etc.

  
  As someone who has really enjoyed Packer in the past -- you really ought to open yourself up to change, my friend. I think JFormDesigner / FormLayout is a vastly superior approach. Would love to chat more with you on this subject.

  
  I agree WRT to open source stuff. I haven't enjoyed Eclipse. I like JFormDesigner because I can use it with any IDE. So, IntelliJ IDEA and JFormDesigner have been a great option.
  

  Posted by: javaben on August 08, 2005 at 09:12 PM

• Hi Ben
  Having just come across this blog, I wonder if you would find interesting some
  work I've been doing at http://superficial.sourceforge.net.

  One way of looking at Superficial is as a GUI builder on steroids, in that
  it allows you to define the GUI as a generalised 'surface', completely abstracting
  away the specific toolkit.
  Superficial is sufficiently complex that it needs a white
  paper, so I've attempted to demonstrate its use with a detailed worked
  example based on Martin Fowler's GUI
  patterns papers.
  Regards, David Wright

  Posted by: dimwight on September 30, 2005 at 02:09 AM

• This is an awesome blog. Lots of great information.
  I think the formlayout by JGoodies is the way to go. We have our own version of XUL that uses the formlayout and allows the UI to be changed by changing an XML file and pressing a fuction key to see your changes without restating your app. The XML is simple and binds to our BO tier. Howerver, JFormDesigner looks like an easier way to do the iterative development of the UI, at least for prototyping.
  Check out this GridBag Animation
  , regading the GridBagLayout, that an employee of SUN gave to me when he came to visit my company.
  

  Posted by: geberhart on August 30, 2006 at 03:32 PM

This work is licensed under a Creative Commons License.