Is it possible to dynamically generate decent looking properties dialogs?

Question

I have an application which displays properties dialogs for various GUI-accessible objects. Because there are a huge number of different kinds objects, there are also a huge number of different properties dialogs. Because we are lazy, we didn't want to hand-build each and every properties dialog; additionally, plugins might introduce new kinds of objects which also need properties dialogs, and it would be nice if plugin designers didn't need to hand-code properties dialogs, either (both to save them work, and to ensure that the result is uniform). Instead, we built a framework which maps properties of these objects to GUI components (e.g., checkboxes, text fields, combo boxes) and then packs them all into a dialog. This has the advantage of requiring no work on our part for building the dialogs, but the dialogs also look like we didn't put any work into laying them out: They look like stacks of Jenga blocks. These dialogs are embarrassing to look at.

So, my question is: Is there any way to automatically layout properties dialogs so they don't look so utterly ugly? (I realize that the answer to this might be "No", but it might also be the case that we just haven't been sufficiently creative in thinking about better ways.) NB: We're working with Java Swing, but really the problem itself is language-agnostic.

Answer 1

One suggestion: If your properties are named with a dot delimited hierarchical format you could dynamically build a JTree to represent the various groups of properties. When a user clicks on a given node in the tree you could display the properties in that category within a JTable on a separate JPanel (e.g. as name-value pairs). You could also enrich the GUI by adding a JTextField where the user could search for a property.

This way, at least you don't present a mass of information all on the same screen ... although the downside is your GUI will end up looking like Regedit :-)

When editting properties you could use reflection to determine the type of property and hence applicable cell editor; e.g.

• For enums you could present a JComboBox based editor.
• For numerical values you could present a JSpinner or JFormattedTextField.
• For boolean values you could present a JCheckBox based editor.

Answer 2

I think you can use XUI to mention your widgets in XML, the good part is it also allows to specify layouts in XML. These are exactly the places I recommend using XUI, though they claim it could be used for building entire applications, I deny. Also as its a common xui stanard for Swing, it also makes your project more standardised.

Answer 3

There are loads of GUI Frameworks that have 'solutions' for 'Property Views' and you might want to have a look at them before you re-invent the wheel. I apologize if you have already seen them and think they suck :)

Here is a PDF for the JIDE one which also shows the NetBeans and JBuilder ones.

Answer 4

I would put my vote as "no", at least for sufficiently discriminating definitions of "automatically" and "don't look so utterly ugly".

This is definitely a common problem: I think at least three of my coworkers have asked for something like this in the last year alone. Unfortunately, I'm not aware of any automated layout solution that doesn't require significant guidance (such as specifying layouts in XUI) in order to work.

Obviously, there are simple things you can do to make your automatically-generated components more easily composable, such as standardizing widths and heights of labels and content. There are also some heuristics that you can apply that might help, such as sorting properties by control type so that all of the combo boxes go together, all of the text fields go together, etc.

However, good GUI layout is hard, and even human programmers often seem to do a pretty poor job of it. This is why I'm not surprised that no one has developed a general automated layout tool that doesn't require specifying a lot of additional information about how the automatically-generated controls are to be presented.

Answer 5

I'd suggest an approach using annotations to drive your GUI framework. That way your back-end objects can declare, for example, which properties are most important and should be shown at the top of the UI (or in the "simple" UI, or on the first tab of a tabbed dialog, or whatever). You could also use this to override the automatically-detected widget provided by default in the framework, or declare a validator, etc. etc.

Armed with this kind of information, your framework could apply all kinds of heuristics for designing friendlier dialogs on the fly. And your plug-in authors could essentially design their own dialogs, at least in broad strokes, without having to write any UI code.