java.lang.Objectjavax.swing.UIManager
All Implemented Interfaces:
java$io$Serializable
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 {@code updateUI} on all {@code JComponents}. The method SwingUtilities#updateComponentTreeUI makes it easy to apply {@code updateUI} to a containment hierarchy. Refer to it for details. The exact behavior of not invoking {@code updateUI} after changing the look and feel is unspecified. It is very possible to receive unexpected exceptions, painting problems, or worse.
swing.defaultlaf
is
{@code non-null}, use its value as the default look and feel class
name.
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.
It's important to note that {@code getDefaults} returns a custom instance of {@code UIDefaults} with this resolution logic built into it. For example, {@code UIManager.getDefaults().getString("Table.foreground")} is equivalent to {@code 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 {@code UIDefaults} with the resolution logic as previously described.
When the look and feel is changed, {@code UIManager} alters only the look and feel defaults; the developer and system defaults are not altered by the {@code 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 {@code 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 {@code 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 java.beans.XMLEncoder .
Thomas
- BallHans
- MullerNested Class Summary: | ||
---|---|---|
public static class | UIManager.LookAndFeelInfo | Provides a little information about an installed
LookAndFeel for the sake of configuring a menu or
for initial application set up. |
Methods from java.lang.Object: |
---|
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
Method from javax.swing.UIManager Detail: |
---|
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.
Note these are not the same as the installed look and feels. |
PropertyChangeListener to the listener list.
The listener is registered for all properties. |
|
|
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.
Note these are not the same as the installed look and feels. |
|
Locale . If the key is not
found or the key doesn't represent
a boolean value then {@code false} will be returned. |
|
|
|
|
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. |
|
|
|
|
|
Icon from the defaults. If the value for
{@code key} is not an {@code Icon}, {@code null} is returned. |
Icon from the defaults that is appropriate
for the given locale. If the value for
{@code key} is not an {@code Icon}, {@code null} is returned. |
Insets object from the defaults. If the value
for {@code key} is not an {@code Insets}, {@code null} is returned. |
Insets object from the defaults that is
appropriate for the given locale. If the value
for {@code key} is not an {@code Insets}, {@code null} is returned. |
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 {@code
LookAndFeel} objects, {@code LookAndFeelInfo} maintains the
class name of the {@code LookAndFeel} class, not the actual
{@code LookAndFeel} instance.
The following example illustrates setting the current look and feel from an instance of {@code LookAndFeelInfo}: UIManager.setLookAndFeel(info.getClassName()); |
|
|
null . |
In general, developers should use the {@code UIDefaults} returned from {@code getDefaults()}. As the current look and feel may expect certain values to exist, altering the {@code UIDefaults} returned from this method could have unexpected results. |
PropertyChangeListener s added
to this UIManager with addPropertyChangeListener(). |
|
|
|
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. |
|
|
|
|
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.
Note these are not the same as the installed look and feels. |
PropertyChangeListener from the listener list.
This removes a PropertyChangeListener that was registered
for all properties. |
|
A value of {@code null} can be used to set the look and feel to {@code null}. As the {@code LookAndFeel} is required for most of Swing to function, setting the {@code LookAndFeel} to {@code null} is strongly discouraged. This is a JavaBeans bound property. |
|