I. Introduction
Building GUIs involves several technical issues such as the definition of each components' layout, the minimum (and maximum) sizes of each component, the containment hierarchy, the interaction behavior of each component, the integration with the core software, and the portability of the interface itself both among different projects and different systems. As this work focuses only on the layout problem, the interaction between the GUI and the software is beyond the scope of this document. One central problem in GUIs is to define how components are placed within a window and how the components size changes when the window is resized. This is commonly refereed to as defining the layout of a GUI. Various solutions for the definition of layouts have been proposed, [1] [2][3] [4]. Most commercial toolkits make one or more of these solutions available to programmers. Using the Java/Swing terminology, some simple examples are the fixed-position layout, grid layout, flow layout, row and column layout, but all of these can only deal with restricted problems. A very flexible and powerful mechanism is the Struts and Springs layout [5] that uses constraints to define the positions of components. This is implemented in the SpringLayout included in the latest Java Virtual Machine. The downside of the Struts and Springs method is that computing the layout requires quite a bit of computational resources. All of the above layout methods aim to make the process transparent for the graphic designer. However, as we will see later, none of them have reached a satisfying abstraction level that permits the graphical designer to ignore implementation problems. Furthermore, the problem of defining user interfaces independently of the implementation in a portable way is addressed by a combination of the MVC (Model-View-Controller) programming pattern and storing the layout in external files, typically using some form of structured file format.