One of the things that’s tough for developers to do in Java is create a slick looking Java Swing application. In the past, I’ve received cut gifs and screenshots from our in-house graphic artist and spent days fighting with the Java Swing API to get them laid out on the panel looking like they’re supposed to. Tweaking graphical look and feel of a page can be incredibly time consuming for developers whose time would be better spent writing business logic.
We tried an experiment with our latest project in that a developer created unbranded plain-looking Swing forms, took screen shots of them, and then gave them to our graphic artist. Our graphic artist then loaded up the Sun NetBeans IDE and crafted the forms for us using the fairly slick drag and drop GUI form creation utility of NetBeans. She then handed the generated Java code back to us and we wired it up and were good to go.
From the developer’s perspective, I would have to say the experiment was an unqualified success. There’s nothing like being handed a fully dressed up Java Swing form where all we have to do is plug in our event handlers.
From the graphic artist’s perspective, however, it was not as exciting an experience. Working within the limitations of Java Swing is NOTHING like working in Photoshop. She was constantly fighting with the layout manager which kept moving and resizing things she didn’t want moved and resized. NetBeans comes out of the box with a number of layout managers, but one of them is clearly more sophisticated than the rest, offering guidelines to line up controls horizontally or vertially etc. None of the layout managers seemed to do what she wanted. You can get complete freedom if you run without a Layout Manager but then your form gets messed up if the user needs to resize the form (e.g. to run on a lower resolution screen). The one catch with using the sophisticated layout manager is that if you want to use the generated form outside of NetBeans (we developed in Eclipse) then you need to add the netbeans jar file called swing-layout-1.0.jar.
The other point of pain for the artist were the limits of Swing itself. Why JPanel has no setImage() method to set a background image is unforgivable in this day and age. Our artist had to go with a flat blue coloured background when she wanted a nice looking image. There is a way in the code to overload the paint() method of your JPanel to draw a background image but I mean, COME ON!
One good thing about putting a tool in the hands of the graphic artist that creates working Swing forms is that it exposes to the graphic artist the hard limitations of the Swing framework, and avoids getting into the situation where the graphic artist designs screens that are nigh impossible to render in Swing.
I was hoping that there might be available a more sophisticated palette one could plug into NetBeans that allowed for slicker looking controls. JGoodies is a popular set of Swing widgets. The only page I could find for making JGoodies widgets available to Netbeans was out of date and didn’t work with the latest version of Netbeans. I was expecting to find a library of publicly available palettes to choose from, but I wasn’t able to find one. So for now we’re stuck with Swing which as far as I’m concerned is a great set of UI widgets if it were THE EARLY 1980’s! <Rant about how superior .NET is at this stuff removed for personal safety reasons>
So all in all, I would say that from the developer’s perspective, using NetBeans as an interface hand-off point between an in-house graphic artist and a developer team is, given the current limitations of Swing, by far and away the most efficient hand-off boundary for developers receiving Swing forms from graphic artists. From the graphic artist’s perspective, there is a lot of frustration involved.