Java AWT / SWT / Swing：如何规划GUI？

Question

I've already realized some applications with a small graphical user interface. Nothing complex, but I've encountered several problems that components aren't displayed or just not behaving as expected.

Now my question:

How do you plan those user interfaces? What do you do when you need to make changes? How do you debug strange behaviours?!

This applies for nearly every type of gui-design. Sure, with Microsofts Visual Studio you have a big advantage because you nearly get what you see in the designer.

Does a good and open-source (or freeware) designer for AWT exist? Already looked around and didn't find anything really intelligent.

EDIT: Until now, I've also created all of my GUIs by hand. Sure it is cleaner code but sometimes it's very hard to find the layouting bugs. If Visual Studio by MS is able to create approximately clean code, why aren't the others?

I've heard about some Eclipse Visual designer. Is that one already production-ready?

Answer 1

I'm not a big fan of GUI builders: They typically autogenerate bucket-loads of code that then locks in your whole development team to using one IDE. Also, this code is often unreadable (check the code generated when using Matisse under Netbeans).

My recommendations for GUI design / debugging would be:

• Add a main method to each panel (or "top-level" component) implementation, allowing other developers to easily determine what a component looks like.
• Favour the use of Action s over ActionListener s and register these actions with each JComponent 's ActionMap . This allows them to be "extracted" and added to other parts of the UI (eg JToolBar ) whilst still having their state controlled by the "owning" JComponent (ie loose coupling).
• Use assert to ensure that all UI component modifications are occurring on the Event Dispatch thread; eg assert SwingUtilities.isEventDispatchThread() .
• To debug strange layout behaviour consider painting a component's background in red!
• Centralise the capturing and reporting of workflow events and exceptions. For example, I typically implement a TaskManager class that is registered with my UI's status bar. Any background processing (performed within SwingWorker s) is passed a handle to a Task created by the TaskManager . Interracting with the Task (by calling setDescription(String) , setThrowable(Throwable) , cancel() ) causes the status bar to be updated. It also causes the glass pane to be displayed for "global" tasks ... but this is all decoupled / hidden from the individual SwingWorkers.
• Do not use the Observer / Observable classes, but instead favour ChangeListener , PropertyChangeListener or your own custom listener implementation for propagating events. Observer passes an Object as it's event, forcing client code to check the type using instanceof and to perform downcasts, making code unreadable and making relationships between classes less clear.
• Favour the use of JTable over JList , even in situations where your table only has one column. JList has some nasty features in its API including the fact that you need to provide a prototype value for it to calculate its size correctly.
• Never use DefaultTableModel as it typically results in you storing your "model" data in two places: In your actual business objects and also within the 2D array that DefaultTableModel sits on. Instead, simply subclass AbstractTableModel - It's very easy to do this and means your implementation can simply delegate through to the data structure (eg List ) storing your data.

Answer 2

I'm one of those archaic dudes who do GUI layout by hand. I'm also not afraid of the infamous GridBagLayout !

I keep things simple for myself by emulating the coding standard used by Visual Age, years ago: I use a lot of JPanels to organize parts of the GUI, and each one gets its own makeXXX() method to create it, lay it out and return it to aa parent panel or the constructor. That way, each makeXXX only has to concentrate on a small part of the whole works.

Some components need to be accessible by various instance methods; I declare those as instance fields. The other stuff, that's just decoration or layout, need not be exposed outside the makeXXX methods.

That's mostly it. Works for me.

Answer 3

Do it by hand. GUI builders aren't good unless you have the 'partial class' concept in C#, and even then they often cause more problems than they solve. Use the GUI builder tools to make a prototype - sure, but not for production code.

Also, another little trick I've used over the years to good effect when trying to debug layout or "which panel am I really seeing here" problems is to give each 'container' panel a really garish background color (yellow, blue, etc). Something obvious enough that you'll see it even if it's only one pixel wide.

And my favorite layout for simple dialogs is BoxLayout. It's not great, you have to write a lot of boilerplate, but at least it generally works the way you would expect it to in your head. Don't overthink layouts until you have to.

Answer 4

There has been a temporarily-dead (but now apparently at least half-alive) plugin for Eclipse for visual GUI design and Netbeans still has support for it. The resulting code was less than stellar, though. At least for people having to work with that codebase afterwards it's quite a pain.

As for me I tend to plan on paper beforehand and try to get all nestings of panels with their layouts right on the first try. Java GUI code is inherently write-only in my experience.

Last time I did such a thing I first created every control I needed and then pieced it together in multiple panels and layouts, etc. That way was at least manageable and worked without too much pain when changes had to be made.

I tend not to think too much about the particular layout in Winforms and WPF due to the, as you noted also, strong designer support. Also WPF is very easy to handle even in XAML. Ans partial classes make working with partly designer-generated and partly handwritten code very pleasant. Alas, no such thing in the Java world.

Answer 5

NetBeans might the best option for building GUI in WYSIWYG manner but many java developers write their GUI by hands, as it is not that difficult. Care about the thickness of your borders and gaps between your controls and you're ok :)

Answer 6

Apart from tools discussion, just some ideas and thoughts

1. Before you touch the keyboard, draw the GUI elements on paper. Like the classic storyboard used for video production. If you have customers, use the hand-drawn (!) designs to communicate the ideas (.. just read, that you already plan on paper)
2. Plan to implement a model-view-controller (MVC) or model-view-presenter pattern
3. Databinding is a great technique to consider. It guarantees synchronisation between your model (data) and the view (GUI) and offers input validation, on-the-fly conversion and many more useful things (Provided the link for JFace databinding, but I'm sure, there are other frameworks for Swing/AWT as well)

Answer 7

I use JFormDesigner for gui generation. It generates nice clean java code, and I've learned a few things from reading through the generated code. Makes localization a snap.

It's a really quick way to throw together an involved layout, especially complex menubars and grid layouts.

Answer 8

I for myself use

Pencil

for some prototyping first, then start coding "by hand" (ie not using any GUI editor).

Answer 9

I would suggest you to use netbeans for GUI development in AWT/SWING.

Regards, Sameer

Answer 10

While NetBeans' Matisse editor is admittedly handy, the code it produces is fairly esoteric and the layouts are fragile. So I've been taking best of both worlds, using NetBeans for WYSIWYG prototyping and then later recoding the whole thing by hand.