GridBagLayout

There are 3 significant advantages that GridBagLayout has over GridLayout:
  1. the rows and columns can all be of different sizes
  2. a component can span multiple cells
  3. it is possible for components to be smaller than the cell area to which they are allocated
The GridBagLayout class determines the size of each cell in the grid. The class has a "helper" class called GridBagConstraints that (among other things) determines the number of cells per component. It is important to distinguish between cell and component. The term "cell" refers to the grid locations (or rectangles) allocated to a component, whereas the term "component" refers to the space within those cells actually occupied by the Java component. It is not required to specify the size of the grid (the number of cells) because the layout object can deduce the number of cells required from the information that is supplied by the developer. The managed components do not need to be added in any particular order.

GridBagLayout uses the 2-argument form of Container's add() method - 

   void add( Component c, Object constraints );
The second parameter is an instance of class GridBagConstraints. [Note: BorderLayout also uses the 2-argument add() method - the second parameter is simply an instance of class String.]

All the members of class GridBagConstraints are public attributes, so they are assigned directly. You can routinely initialize the attributes on first use, and then reuse most of the settings for all subsequent invocations of add(). This means that only the constraints that must be changed are actually modified. [GridBagLayout makes its own copy of the constraints object passed to add(), so the programmer can reuse his/her copy.]   GridBagConstraints' attributes are:

gridx and gridy. A shorthand feature for laying out components across a row or down a column is the GridBagConstraints.RELATIVE constant. Using this constant tells the GridLayout object to add one to the gridx or gridy attribute each time it is passed to add(). The example below will create three buttons aligned in a row. 
   gbc.gridx = GridBagConstraints.RELATIVE;
   p.add( new JButton("1"), gbc );
   p.add( new JButton("2"), gbc );
   p.add( new JButton("3"), gbc );
gridwidth and gridheight. The constant GridBagConstraints.REMAINDER provides a similar shortcut for attributes gridwidth and gridheight. The tagged component will span the remainder of the row and/or column it has been assigned to. "This facility allows you to create components that span the right number of rows or columns even if you add extra components to the layout and change the number of components in the direction concerned." [Topley, p136]

weightx and weighty. These values specify how extra space in the container should be distributed among its components in the x and y dimensions. They do not have to add up to 1.0 in a given dimension. What is important is the ratio of a weightx value to the sum of all weightx values. If two or more components have the same weight value, they will "share equally in any extra pixels that come along". A weight of 0.0 means: the component should originally be laid-out right next to its neighbor, and, the component's cell should not be resized in that dimension when its container is resized.

"The weight feature is useful for the same reason that the border layout manager is useful: when the container resizes, some components should resize, some should resize in just one direction, and some should remain as they are." [Heller, p122]

fill. Specifies which dimensions of a component should grow when the space available for it is larger than its default size. The legal values are:

Setting fill to VERTICAL (or BOTH) will cause all components on the same row to have their centers aligned vertically. Setting fill to HORIZONTAL (or BOTH) will cause all JButtons in the same column to have the same width (regardless of the width of their labels).

anchor. Defines how the component should be displayed within its grid cells when it is smaller than those cells. The legal values are:

There is a connection between anchor and fill. If a cell has a fill value that allows its component to expand in a certain direction, then the anchor constraint for that direction is ignored. For example, if a component has a fill of HORIZONTAL, then it will automatically stayed anchored to the west and east of its cell.

insets. An object that encapsulates the margins to be used on all sides of the component.

ipadx and ipady. These fields specify internal padding to add on each side of the component in each dimension. They increase the size of the component beyond its default minimum size.


Example

When the example is run, the window displays five rows and five columns of buttons. Button 1 occupies multiple rows and columns (and claims all additional real estate resulting from resize operations) because it is the only button with weightx and weighty values. The non-intuitive features of this example are: button 4 has a gridheight of two, and buttons 5 through 9 have a gridy that is one greater than it should be.

Apparently, GridBagLayout noticed that no buttons were added to row 3, so it did not allocate real estate for a row with no components (but it still created a "placeholder" internally [?] ), and, it did not give button 4 a height of two cells. Only when the window is enlarged vertically does button 4 start to exhibit a height that is greater than one.

Because of the weightx and weighty values for button 1, it should absorb all increases in window size. Notice that any component that shares the same row as the bottom of button 1, or the same column as the right side of button 1, grows in unison with button 1.

[Reference: Topley, pp129-150]