Home | Blog | Java | Jokes | Poems | Musings | Site Map | Kudos | Downloads | Useful Sites | Interesting | System Setup | Contact

Home Page

AKGBackup - The backup program



Section 8 : The java.awt Package

Write code using component, container, and LayoutManager classes of the java.awt package to present a GUI with specified appearance and resize behavior, and distinguish the responsibilities of layout managers from those of containers.



Layout Managers


There are two reasons for Java using layout managers.


Firstly, precise layout is a repetitious and often performed task. Therefore, according to the principles of OOP, layout functionality ought to be encapsulated into one or more classes to automate the task.


The second and practical reason stems from Javaís platform independence. Java components borrow their behavior from the window system of  the underlying hardware on which JVM is running. The problem here is that buttons and other components have different sizes when instantiated on different platforms. If Java encouraged precise pixel level sizing and positioning, there would be a lot of Java GUIs that looked exquisite on their platform of origin and terrible on others. Java deals with this problem by delegating precision layout work to layout managers.


Containers and Components


When a container is constructed, it is given a default layout manager. A container confers with its layout manager to determine where components will be placed and (optionally) how they will be resized. If the container subsequently gets resized, the layout manager again lays out the components. 


Component size and position


A componentís size and position can be changed by calling its setBounds() method. Generally, this call proves to be useless since layout managers usually have the last word. It is they who decide the size and position of the component, since their call to the componentís setBounds() occurs after any calls to this method by the program. If you wish to have control over the size then probably it is best to use FlowLayout.


Layout policies


Every Java component has a preferred size. The preferred size expresses how big the component would be without intervention by a layout manager. Preferred size is the smallest size necessary to render the component in a visually meaningful way. Preferred size is platform dependent, since component boundary decorations vary from system to system.


When a layout manager lays out its containerís child components, it has to balance two considerations: the layout policy and each componentís preferred size. First priority goes to enforcing layout policy. If honoring preferred size would mean violating the layout policy, then the layout manager overrules the preferred size.




This layout manager always honors a componentís preferred size.


It arranges components in horizontal rows. It is the default manager for Panels and Applets. It fits as many components as possible into the top row, left to right in the order they were added, and spills the remainder into second row.


Within each row the components are centered and evenly spaced. The justification of the clustering can be controlled by passing a parameter (FlowLayout.LEFT, FlowLayout.RIGHT and FlowLayout.CENTER)  to FlowLayout constructor.


The default gap between components is 5 pixels in both the horizontal and vertical directions. This gap can be changed using another of its constructors.


  1. FlowLayout()

  2. FlowLayout(int justification)

  3. FlowLayout(int justification, int hGap, int vGap)




This layout manager always ignores a componentís preferred size.


The GridLayout class is a layout manager that lays out a container's components in a rectangular grid. The container is divided into equal-sized rectangles, and one component is placed in each rectangle.


Components appear in the order they were added, from left to right, row by row.


  1. GridLayout()

  2. GridLayout(int rows, int columns)

  3. GridLayout(int rows, int columns, int hgap, int vgap)




This is default manager for Frames. It divides its territory into 5 regions: BorderLayout.NORTH, BorderLayout.SOUTH, BorderLayout.EAST, BorderLayout.WEST, and BorderLayout.CENTER. Each region can contain one component. This layout is not affected by the order in which components are added. Instead you must specify which of the five regions will receive the component you are adding. 


The manager honors the preferred height of components in the north and south and forces them to be exactly as wide as the container. The north and south regions are useful for toolbars, status lines and any other controls that ought to be as wide as possible, but no higher than necessary.


In east and west, a component gets to be its preferred width but the height extends from bottom of the north component (if there is one) or to the top of the container (if there is no North component), to the top of the South component (if there is one) or to the bottom of the container (if there is no south component).


The fifth region is Center which is simply the part of a container that remains after north, south, east and west have been allocated. When adding a component to center, it is legal to omit the second parameter to the add() call; the layout manager assumes  that you meant center.




This is the most complicated layout manager. It divides its container into an array of cells, but different cell rows can have different heights, and different cell columns can have different widths. A component can occupy a single cell or it can span many cells. This manager requires a lot of information to know where to put a component. A helper class GridBagConstraints is used hold the layout information. When you add a component, you use the add(component, object) version of the add() method, passing an instance of the GridBagConstraints as object parameter.


To provide the layout information different fields of the GridBagConstraints class are required to be set. These fields are:



          This field is used when the component is smaller than its display area.

static int

          Resize the component both horizontally and vertically.

static int

          Put the component in the center of its display area.

static int

          Put the component on the right side of its display area, centered vertically.


          This field is used when the component's display area is larger than the component's requested size.


gridheight, gridwidth
          gridheight specifies the number of cells in a column for the component's display area and gridwidth specifies the number of cells in a row for the component's display area. The default is 1 for both and both should be non negative.


          Specifies the cell at the left of the component's display area, where the leftmost cell has
gridx=0. Default value is RELATIVE.


          Specifies the cell at the top of the component's display area, where the topmost cell has
gridy=0. Default value is RELATIVE.

static int

          Resize the component horizontally but not vertically.


          This field specifies the external padding of the component, the minimum amount of space between the component and the edges of its display area. If any of the values used for insets is negative, this has the effect of allowing the component to expand outside its display area.


          This field specifies the internal padding of the component, how much space to add to the minimum width of the component.


          This field specifies the internal padding, that is, how much space to add to the minimum height of the component.

static int

          Do not resize the component.

static int

          Put the component at the top of its display area, centered horizontally.

static int

          Put the component at the top-right corner of its display area.

static int

          Put the component at the top-left corner of its display area.

static int

          Specify that this component is the next-to-last component in its column or row (
gridwidth, gridheight), or that this component be placed next to the previously added component (gridx, gridy).

static int

          Specify that this component is the last component in its column or row.

static int

          Put the component at the bottom of its display area, centered horizontally.

static int

          Put the component at the bottom-right corner of its display area.

static int

          Put the component at the bottom-left corner of its display area.

static int

          Resize the component vertically but not horizontally.


weightx specifies how to distribute extra horizontal space and weighty specifies how to distribute extra vertical space.

The layout manager calculates the weight of a column to be the maximum weightx of all the components in a column. If the resulting layout is smaller horizontally than the area it needs to fill, the extra space is distributed to each column in proportion to its weight. A column that has a weight of zero, all the extra space appears between the grids of the cell and the left and right edges. The default value is zero.

Same is true for weighty which handles rows.

static int

          Put the component on the left side of its display area, centered vertically.





It lays out its components in time rather than in space. At any moment, a container using this manager is showing one or another of its components; all the other components are unseen. A method call to the layout manager can tell it to display a different component. All the components (which are usually panels) are of its components; all the other components are unseen. A method call to the layout manager can tell it to display a different component. All the components (which are usually panels) are resized to occupy the entire container. The result is similar to a tabbed panel without the tabs.


No layout manager


To use no layout manager, just call setLayout(null);

If a container has no layout manager, it honors each componentís x, y, width and height values. So you can call setBounds() on a component, add it to a container and have the component end up where you want it to be. The problem with this approach is that if your container resides in a larger container that gets resized, your layout may need to be redone to save components from being overlaid or clipped away. People who do this find that they have to write code to detect when the container resizes and more code to do the right things when resizing occurs. This ends up being more complicated than creating your own layout manager.



section8-1-1 | section8-1-2 | section8-1-3 | section8-2

Sections : 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11








Home | Blog | Java | Jokes | Poems | Musings | Site Map | Kudos | Downloads | Useful Sites | Interesting | System Setup | Contact  


 Number of Pages viewed on this site since January' 2003 : Hit Counter eXTReMe Tracker

For any queries, comments or suggestions, write to me .

This site never compromises your privacy, please read this site's privacy policy.