The Swing Changes and New Features for Java 2 SDK, Standard Edition, v 1.4 document describes changes for all the 1.4.* releases. This document provides links to changes specific to the 1.4.1 and 1.4.2 releases.
For Swing, this release primarily features bugfixes. Bugs that have been fixed include:
Focus related bugs:
Drag and drop related bugs:
Miscellaneous:
In addition to many bugfixes, this release features these new enhancements:
The bugtraq reports that correspond to this change are: 4679673 and 4712307.
This release features many performance improvements to
JFileChooser. In some situations,
JFileChooser now performs 300 times faster.
Release 1.4.2 introduces support for the standard Microsoft
Windows XP appearance as the default when running on the Windows XP
platform. This look and feel automatically appears if your app is
using Swing's WindowsLookAndFeel class (either by way
of UIManager.getSystemLookAndFeelClassName() or by
explicitly using
com.sun.java.swing.plaf.windows.WindowsLookAndFeel) on
a machine running the Windows XP operating system. The following
example illustrates the preferred way of setting the look and feel
to match that of the native platform:
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
If you prefer your Swing app to look like a classic Windows app
you can turn of the XP look using the system property
swing.noxp=true. This is typically used as a command
line parameter, eg:
java -Dswing.noxp=true -jar SwingSet2.jar
Note that the swing.noxp property may not be
supported in future releases.
Release 1.4.2 introduces a look and feel based on GTK+ 2.0. In order to get this look and
feel you need to explicitly ask for it by way of
UIManager.setLookAndFeel("com.sun.java.swing.plaf.gtk.GTKLookAndFeel")
or by defining the system property swing.defaultlaf to
be com.sun.java.swing.plaf.gtk.GTKLookAndFeel. In the
next release we will make
UIManager.getSystemLookAndFeelClassName() return this
look and feel when appropriate.
The GTK+ look and feel can be customized by way of resource files. Swing's GTK+ look and feel uses the following algorithm to locate the resource files:
swing.gtkthemefile exists,
parse it and stop, for example: java
-Dswing.gtkthemefile=/tmp/customTheme -jar
SwingSet2.jar.user.home/.gtkrc-2.0 exists, parse it
and continue.gnome.net/ThemeName which is
determined using
XSETTINGS. If this property is null, use Default
as THEMENAME.
user.home/.themes/THEMENAME/gtk-2.0/gtkrc exists parse
it and stop.swing.gtkthemedir exists
and the file swing.gtkthemedir/THEMENAME/gtk-2.0/gtkrc
exists, parse it and stop.swing.gtkthemedir doesn't
exist and the file
/usr/share/themes/THEMENAME/gtk-2.0/gtkrc exists,
parse it and stop.swing.gtkthemedir is defined parse
swing.gtkthemedir/THEMENAME/gtk/gtkrc, otherwise parse
/usr/share/themes/THEMENAME/gtk/gtkrc.One way GTK+ can be customized is by way of a theme
engine. A handful of engines exist. In 1.4.2, Swing supports
theme files for Default, pixmap, and
bluecurve engines. We are investigating ways to open
up the API to allow for the creation of additional GTK engines.
Visit http://www.themes.org for
examples.
GTK+ allows for specifying fonts in two ways: using an XLFD
or using a pango string. Pango
provides for facilities similar to the composite Fonts on the Java
platform, that is, a font that consists of a number of different
fonts for different code points. Because pango's composite fonts do
not exactly match Java's composite fonts, a Swing app with the
GTKLookAndFeel will not exactly match a native GTK+
app. We are investigating ways to deal with this. One option is to
replace your pango font file with a version equivalent to Java's
font.properties file. Additionally we currently ignore XLFDs and
pass Pango strings (after mapping sans to sansserif and monospace
to monospaced) directly to a java.awt.Font.
GTK+ does not provide MDI (JInternalFrame)
capabilities nor does it directly support theming of top level
windows, rather that is left up to the WindowManager. For Swing's
MDI classes we support theming by way of Metacity.
We currently only support the Crux and
Bluecurve themes. If we can not locate either of these
themes we fall back to our own custom theme. You can use the system
property swing.metacitythemename to name a particular
theme to use, otherwise we will look in
user.dir/.gconf/apps/metacity/general/%gconf.xml to
determine the name of theme and look in
/usr/share/themes/THEMENAME/metacity-1/metacity-theme-1.xml
or
/usr/gnome/share/themes/THEMENAME/metacity-1/metacity-theme-1.xml
for the actual resource file. The following example shows how to
trigger Swing to use a specific metacity theme:
java -Dswing.metacitythemename=Bluecurve -jar SwingSet2.jar
GTK+ resource files allow for customizing a number of look and feel options beyond the look. In 1.4.2 we support the primary style configurations (fg, bg, base ..), gtk-font-name, gtk-icon-sizes, stock icons (for optionpane), focus-line-width, focus-padding, focus-line-pattern, internal-padding, shadow-type (for menubars), and trough-border.
GTK provides a mechanism for which running applications can pick up a theme change and automatically update the UI, this will be supported in a future version of Swing's GTK look and feel.
Correctly supporting a GTK+ look and feel posed a number of challenges to Swing's current architecture. In Swing an opaque component ALWAYS paints its background by way of ComponentUI's update method, in GTK+ a nonopaque component may or may not paint the background, depending upon the engine. To correctly mirror GTK+ a number of Components that previously were opaque have been made nonopaque (by way of the ComponentUI subclass's installUI method). Additionally because the look of a component can change based on the containment hierarchy the opacity may change after the constructor has completed. A ramification of this is that if you invoke setOpaque() on a component, it may change out from under you. We will fix this in the next release.
GTK+ calls into the engine to paint border decorations before the actual contents of the widget are painted. Some engines, most notably the pixmap engine, rely on this ordering to correctly render decorations behind the contents. In Swing the border is rendered after the widget contents are painted. In the GTKLookAndFeel we install a Border only to provide space, and let the UI do the actual rendering of the border decorations as part of the paint method. The ramification of this is that if you install a Border on a widget with the GTKLookAndFeel you will likely not get the effect you are after. Again, we are investigating alternatives and will provide a better solution in the next release.
