Class UIManager

UIManager manages the current look and feel, the set of
available look and feels, PropertyChangeListeners that
are notified when the look and feel changes, look and feel defaults, and
convenience methods for obtaining various default values.

Specifying the look and feel

The look and feel can be specified in two distinct ways: by
specifying the fully qualified name of the class for the look and
feel, or by creating an instance of LookAndFeel and passing
it to setLookAndFeel. The following example illustrates
setting the look and feel to the system look and feel:

UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());

The following example illustrates setting the look and feel based on
class name:

UIManager.setLookAndFeel("javax.swing.plaf.metal.MetalLookAndFeel");

Once the look and feel has been changed it is imperative to invoke
updateUI on all JComponents. The method SwingUtilities.updateComponentTreeUI(java.awt.Component) makes it easy to apply updateUI to a containment hierarchy. Refer to it for
details. The exact behavior of not invoking updateUI after changing the look and feel is
unspecified. It is very possible to receive unexpected exceptions,
painting problems, or worse.

Default look and feel

The class used for the default look and feel is chosen in the following
manner:

If the system property swing.defaultlaf is
non-null, use its value as the default look and feel class
name.

If the Properties file swing.properties
exists and contains the key swing.defaultlaf,
use its value as the default look and feel class name. The location
that is checked for swing.properties may vary depending
upon the implementation of the Java platform. In Sun's implementation
the location is ${java.home}/lib/swing.properties.
Refer to the release notes of the implementation being used for
further details.

Otherwise use the cross platform look and feel.

Defaults

UIManager manages three sets of UIDefaults. In order, they
are:

Developer defaults. With few exceptions Swing does not
alter the developer defaults; these are intended to be modified
and used by the developer.

Look and feel defaults. The look and feel defaults are
supplied by the look and feel at the time it is installed as the
current look and feel (setLookAndFeel() is invoked). The
look and feel defaults can be obtained using the getLookAndFeelDefaults() method.

Sytem defaults. The system defaults are provided by Swing.

Invoking any of the various get methods
results in checking each of the defaults, in order, returning
the first non-null value. For example, invoking
UIManager.getString("Table.foreground") results in first
checking developer defaults. If the developer defaults contain
a value for "Table.foreground" it is returned, otherwise
the look and feel defaults are checked, followed by the system defaults.

It's important to note that getDefaults returns a custom
instance of UIDefaults with this resolution logic built into it.
For example, UIManager.getDefaults().getString("Table.foreground")
is equivalent to UIManager.getString("Table.foreground"). Both
resolve using the algorithm just described. In many places the
documentation uses the word defaults to refer to the custom instance
of UIDefaults with the resolution logic as previously described.

When the look and feel is changed, UIManager alters only the
look and feel defaults; the developer and system defaults are not
altered by the UIManager in any way.

The set of defaults a particular look and feel supports is defined
and documented by that look and feel. In addition, each look and
feel, or ComponentUI provided by a look and feel, may
access the defaults at different times in their life cycle. Some
look and feels may agressively look up defaults, so that changing a
default may not have an effect after installing the look and feel.
Other look and feels may lazily access defaults so that a change to
the defaults may effect an existing look and feel. Finally, other look
and feels might not configure themselves from the defaults table in
any way. None-the-less it is usually the case that a look and feel
expects certain defaults, so that in general
a ComponentUI provided by one look and feel will not
work with another look and feel.

Warning:
Serialized objects of this class will not be compatible with
future Swing releases. The current serialization support is
appropriate for short term storage or RMI between applications running
the same version of Swing. As of 1.4, support for long term storage
of all JavaBeansTM
has been added to the java.beans package.
Please see XMLEncoder.

Constructor Detail

UIManager

Method Detail

getInstalledLookAndFeels

Returns an array of LookAndFeelInfos representing the
LookAndFeel implementations currently available. The
LookAndFeelInfo objects can be used by an
application to construct a menu of look and feel options for
the user, or to determine which look and feel to set at startup
time. To avoid the penalty of creating numerous LookAndFeel objects, LookAndFeelInfo maintains the
class name of the LookAndFeel class, not the actual
LookAndFeel instance.

The following example illustrates setting the current look and feel
from an instance of LookAndFeelInfo:

setInstalledLookAndFeels

Sets the set of available look and feels. While this method does
not check to ensure all of the LookAndFeelInfos are
non-null, it is strongly recommended that only non-null
values are supplied in the infos array.

Parameters:

infos - set of LookAndFeelInfo objects specifying
the available look and feels

setLookAndFeel

Sets the current look and feel to newLookAndFeel.
If the current look and feel is non-nulluninitialize is invoked on it. If newLookAndFeel is
non-null, initialize is invoked on it followed
by getDefaults. The defaults returned from newLookAndFeel.getDefaults() replace those of the defaults
from the previous look and feel. If the newLookAndFeel is
null, the look and feel defaults are set to null.

A value of null can be used to set the look and feel
to null. As the LookAndFeel is required for
most of Swing to function, setting the LookAndFeel to
null is strongly discouraged.

getSystemLookAndFeelClassName

Returns the name of the LookAndFeel class that implements
the native system look and feel if there is one, otherwise
the name of the default cross platform LookAndFeel
class. This value can be overriden by setting the
swing.systemlaf system property.

getCrossPlatformLookAndFeelClassName

Returns the name of the LookAndFeel class that implements
the default cross platform look and feel -- the Java
Look and Feel (JLF). This value can be overriden by setting the
swing.crossplatformlaf system property.

getUI

Returns the appropriate ComponentUI implementation for
target. Typically, this is a cover for
getDefaults().getUI(target). However, if an auxiliary
look and feel has been installed, this first invokes
getUI(target) on the multiplexing look and feel's
defaults, and returns that value if it is non-null.

getLookAndFeelDefaults

Returns the UIDefaults from the current look and feel,
that were obtained at the time the look and feel was installed.

In general, developers should use the UIDefaults returned from
getDefaults(). As the current look and feel may expect
certain values to exist, altering the UIDefaults returned
from this method could have unexpected results.

addAuxiliaryLookAndFeel

Adds a LookAndFeel to the list of auxiliary look and feels.
The auxiliary look and feels tell the multiplexing look and feel what
other LookAndFeel classes for a component instance are to be used
in addition to the default LookAndFeel class when creating a
multiplexing UI. The change will only take effect when a new
UI class is created or when the default look and feel is changed
on a component instance.

removeAuxiliaryLookAndFeel

Removes a LookAndFeel from the list of auxiliary look and feels.
The auxiliary look and feels tell the multiplexing look and feel what
other LookAndFeel classes for a component instance are to be used
in addition to the default LookAndFeel class when creating a
multiplexing UI. The change will only take effect when a new
UI class is created or when the default look and feel is changed
on a component instance.

getAuxiliaryLookAndFeels

Returns the list of auxiliary look and feels (can be null).
The auxiliary look and feels tell the multiplexing look and feel what
other LookAndFeel classes for a component instance are
to be used in addition to the default LookAndFeel class when creating a
multiplexing UI.