Chapter 1. (Introduction) Swing Overview. Easy for reading, Click here!

Subpages: 1. Chapter 1. Swing Overview. AWT, Swing 
2. MVC architecture: Model, View, Controller 
3.  Custom models - II, UI delegates and PLAF 

1.4    UI delegates and PLAF

Almost all modern user interface frameworks coalesce the view and controller, whether they are based on SmallTalk, C++, and now Java. Examples include MacApp, Smalltalk/V, Interviews, and the X/Motif widgets used in IBM Smalltalk.[1] JFC Swing is the newest addition to this crowd. Swing packages each component's view and controller into an object called a UI delegate. For this reason Swing's underlying architecture is more accurately referred to as model-delegate rather than model-view-controller. Ideally communication between both the model and the UI delegate is indirect, allowing more than one model to be associated with one UI delegate, and vice versa. Figure 1.6 illustrates.

Figure 1.6 Model-delegate architecture

<<file figure1-6.gif>>

1.4.1    The ComponentUI class

Each UI delegate is derived from an abstract class called ComponentUI. ComponentUI methods describe the fundamentals of how a UI delegate and a component using it will communicate. Note that each method takes a JComponent as parameter.

ComponentUI methods:

  static ComponentUI CreateUI(JComponent c)

This is normally implemented to return a shared instance of the UI delegate defined by the defining ComponentUI subclass itself. This instance is used for sharing among components of the same type (e.g. All JButtons using the Metal look-and-feel share the same static UI delegate instance defined in javax.swing.plaf.metal.MetalButtonUI by default.)

  installUI(JComponent c)

Installs this ComponentUI on the specified component. This normally adds listeners to the component and/or its model(s), to notify the UI delegate when changes in state occur that require a view update.

  uninstallUI(JComponent c)

Removes this ComponentUI and any listeners added in installUI() from the specified component and/or its model(s).

  update(Graphics g, JComponent c)

If the component is opaque this should paint its background and then call paint(Graphics g, JComponent c).

  paint(Graphics g, JComponent c)

Gets all information it needs from the component and possibly its model(s) to render it correctly.

  getPreferredSize(JComponent c)

Return the preferred size for the specified component based on this ComponentUI.

  getMinimumSize(JComponent c)

Return the minimum size for the specified component based on this ComponentUI.

  getMaximumSize(JComponent c)

Return the maximum size for the specified component based on this ComponentUI.

To enforce the use of a specific UI delegate we can call a component's setUI() method (note that setUI() is declared protected in JComponent because it only makes sense in terms of a JComponent subclass):

    JButton m_button = new JButton();

    m_button.setUI((MalachiteButtonUI)

      MalachiteButtonUI.createUI(m_button));

Most UI delegates are constructed such that they know about a component and its model(s) only while performing painting and other view-controller tasks. Swing normally avoids associating UI delegates on a per-component basis (hence the static instance). However, nothing stops us from assigning our own as the code above demonstrates.

1.4.2 Pluggable look-and-feel

Swing includes several sets of UI delegates. Each set contains ComponentUI implementations for most Swing components and we call each of these sets a look-and-feel or a pluggable look-and-feel (PLAF) implementation. The javax.swing.plaf package consists of abstract classes derived from ComponentUI, and the classes in the javax.swing.plaf.basic package extend these abstract classes to implement the Basic look-and-feel. This is the set of UI delegates that all other look-and-feel classes are expected to use as a base for building off of. (Note that the Basic look-and-feel cannot be used on its own, as BasicLookAndFeel is an abstract class.) There are three pluggable look-and-feel implemenations derived from the Basic look-and-feel:

Windows: com.sun.java.swing.plaf.windows.WindowsLookAndFeel

CDE\Motif: com.sun.java.swing.plaf.motif.MotifLookAndFeel

Metal (default): javax.swing.plaf.metal.MetalLookAndFeel

There is also a MacLookAndFeel for simulating Macintosh user interfaces, but this does not ship with Java 2 and must be downloaded separately. The Windows and Macintosh pluggable look-and-feel libraries are only supported on the corresponding platform.[2]

The multiplexing look-and-feel, javax.swing.plaf.multi.MultiLookAndFeel, extends all the abstract classes in javax.swing.plaf. It is designed to allow combinations of look-and-feels to be used simultaneously and is intended for, but not limited to, use with Accessibility look-and-feels. The job of each multiplexing UI delegate is to manage each of its child UI delegates.

Each look-and-feel package contains a class derived from the abstract class javax.swing.LookAndFeel: BasicLookAndFeel, MetalLookAndFeel, WindowsLookAndFeel, etc. These are the central points of access to each look-and-feel package. We use them when changing the current look-and-feel, and the UIManager class (used to manage installed look-and-feels) uses them to access the current look-and-feel's UIDefaults table (which contains, among other things, UI delegate class names for that look-and-feel corresponding to each Swing component). To change the current look-and-feel of an application we can simply call the UIManager's setLookAndFeel() method, passing it the fully qualified name of the LookAndFeel to use. The following code can be used to accomplish this at run-time:

  try {

    UIManager.setLookAndFeel(

      "com.sun.java.swing.plaf.motif.MotifLookAndFeel");

    SwingUtilities.updateComponentTreeUI(myJFrame);

  }

  catch (Exception  e) {

    System.err.println("Could not load LookAndFeel");

  }

SwingUtilities.updateComponentTreeUI() informs all children of the specified component that the look-and-feel has changed and they need to discard their UI delegate in exchange for a different one of the specified type.

1.4.3    Where are the UI delegates?

We've discussed ComponentUI, and the packages LookAndFeel implementations reside in, but we haven't really mentioned anything about the specific UI delegate classes derived from ComponentUI. Each abstract class in the javax.swing.plaf package extends ComponentUI and corresponds to a specific Swing component. The name of each class follows the general scheme of class name (without the "J" prefix) plus a "UI" suffix. For instance LabelUI extends ComponentUI and is the base delegate used for JLabels.

These classes are extended by concrete implementations such as those in the basic and multi packages. The names of these subclasses follow the general scheme of look-and-feel name prefix added to the superclass name. For instance, BasicLabelUI and MultiLabelUI both extend LabelUI and reside in the basic and multi packages respectively. Figure 1.7 illustrates the LabelUI hierarchy.

Figure 1.7 LabelUI hierarchy

<<file figure1-7.gif>>

Most look-and-feel implementations are expected to extend the concrete classes defined in the basic package, or use them directly. The Metal, Motif, and Windows UI delegates are built on top of Basic versions. The Multi look-and-feel, however, is unique in that each implementation does not extend from Basic, and is merely a shell allowing an arbitrary number of UI delegates to be installed on a given component.

Figure 1.7 should emphasize the fact that Swing supplies a very large number of UI delegate classes. If we were to create an entire pluggable look-and-feel implementation, it is evident that some serious time and effort would be involved. In chapter 21 we will learn all about this process, as well as how to modify and work with the existing look-and-feels.