Swing LayoutManagers hell or the Genesis of DesignGridLayout

Why standard Swing LayoutManagers are bad

  • they are too simple (FlowLayout, GridLayout) to really get your forms as you want them
  • or they are too complex (GridBagLayout) to make for maintainable GUI code
  • they require graphical designers (integrated in your IDE) to generate code that is not human-readable and hard to maintain
  • they allow developers to produce a bad user experience (and most developers are not good at designing visually correct UIs)
  • even Java 6 GroupLayout, although it brings many improvements, is hard (not to say impossible) to use without a graphical designer

Some 3rd-party, open source, LayoutManagers exist and they try to overcome most of the problems above; however, they still have some drawbacks such as:

  • don't prevent developers from producing bad UI
  • often use cryptic strings to define location and sizing behavior of components; without a proper graphical designer, you cannot be sure that these strings typed by developers are correct until you launch the GUI

The genesis of DesignGridLayout

DesignGridLayout was born based on the work from Mullet & Sanno on canonical grids (a tool used in publishing) to produce always balanced and good-looking UI.

From the beginning, one major plus of DesignGridLayout was its API that really helps the work of developers without the need for any graphical designer in the IDE, and with a very short learning curve.

DesignGridLayout "philosophy"

DesignGridLayout was designed with the following important principles in mind:

  • layouts produced through it must always be good looking (in terms of components alignment, spacing, sizing, visual balance, all compliant to the current platform); it must be impossible (or very difficult) for a developer to produce an ugly UI with DesignGridLayout
  • "What You Code Is What You Get": developers and maintainers must be able to immediately "visualize" the resulting UI when browsing source code using DesignGridLayout for it
  • reduced learning curve: DesignGridLayout must provide an API that always guides the developer; this API must enable IDE code-completion and must be as compile-safe as possible; developers should never discover problems with their UI at runtime
  • in the rare cases where it is possible for the developer to write layout code that cannot work, then the produced UI should show hints to the developer and help him quickly fix the layout code
  • existing UIs must be easy to modify; e.g. adding a row to a form should be straightforward for the developer
  • no need for any graphical designer: the API is the graphical designer

To implement these principles, DesignGridLayout has decided to follow a different way of using LayoutManagers than the usual way (please note that this approach is also used by Java 6 GroupLayout): instead of adding Components directly to a Container and specify a String or Object to describe location, size... of that Component, DesignGridLayout uses a fluent API which starts from the DesignGridLayout instance itself.

DesignGridLayout Features (version 1.11)

  • Fluent and simple API to create grid-based layouts (from the layout, you create rows, from a row you add components)
  • Respect of spacing between components (and container edges) based on platform settings (i.e. installed LookAndFeel)
  • Automatic baseline alignment for all components in a row
  • Support for canonical grid rows, left-aligned rows, centered rows and right-aligned rows (useful for command buttons, these rows ensure a uniform width of all their components, even across several such rows)
  • Special "label" columns (in canonical grid rows) that have constant width during horizontal resize (no waste of space after resize); DesignGridLayout supports several groups of columns, each having their dedicated label column. Labels in these columns are aligned according to platform guidelines or can be forced left or right
  • Support for special command bar rows where command buttons are positioned by DesignGridLayout based on the UI guidelines of the current platform, removing the need, in developer's code, to check the platform and add buttons in the right order
  • Support for high components (e.g. JList) spanning several grid rows
  • Smart horizontal resize that preserves the UI balance (by enlarging all components consistently)
  • Smart vertical resize: DesignGridLayout automatically detects rows that should grow in height during vertical resize (based on the components they contain); after resize, JTable, JList, JTextArea components never contain truncated items (row or text line)
  • Dynamic layouts are possible by hiding or showing an entire row or a group of rows in a single API call
  • Row indentation can be used to visually group a set of related rows under a common "parent" row
  • Automatic support for right-to-left languages
  • Total resolution independence: no need for any hard-coded position or spacing
  • New Componentizer API to create a new JComponent from horizontally aligned children, each with various policies for width changes