Swing Changes Since Java 2 SDK, v1.4

Swing Changes Since Java^TM 2 SDK, Standard Edition, v 1.4

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.

Changes for the Incremental Release, Java 2 SDK, S.E., v1.4.1

For Swing, this release primarily features bugfixes. Bugs that have been fixed include:

Focus related bugs:

Drag and drop related bugs:

Miscellaneous:

Changes for the Incremental Release, Java 2 SDK, S.E., v1.4.2

In addition to many bugfixes, this release features these new enhancements:

JFileChooser Performance 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.

Windows XP look and feel

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.

GTK+ look and feel

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:

If the system property swing.gtkthemefile exists, parse it and stop, for example: java -Dswing.gtkthemefile=/tmp/customTheme -jar SwingSet2.jar.

If the file user.home/.gtkrc-2.0 exists, parse it and continue.

Determine the user selected theme name (THEMENAME) by way of the desktop property gnome.net/ThemeName which is determined using XSETTINGS. If this property is null, use Default as THEMENAME.

If the file user.home/.themes/THEMENAME/gtk-2.0/gtkrc exists parse it and stop.

If the system property swing.gtkthemedir exists and the file swing.gtkthemedir/THEMENAME/gtk-2.0/gtkrc exists, parse it and stop.

If the system property swing.gtkthemedir doesn't exist and the file /usr/share/themes/THEMENAME/gtk-2.0/gtkrc exists, parse it and stop.

Lastly if 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.

GTK Incompatabilities

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.

1.4.2 Bugs

One bug worth mentioning:

4759306: JColorChooser.setPreviewPanel does not remove the old one.

Java Technology

Swing Changes Since JavaTM 2 SDK, Standard Edition, v 1.4