Swing Changes Since JavaTM 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.
For Swing, this release primarily features bugfixes. Bugs that have been fixed include:
Focus related bugs:
Drag and drop related bugs:
In addition to many bugfixes, this release features these new enhancements:
This release features many performance improvements to
JFileChooser. In some situations,
JFileChoosernow 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
WindowsLookAndFeelclass (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.noxpproperty 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
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.gtkthemefileexists, parse it and stop, for example:
java -Dswing.gtkthemefile=/tmp/customTheme -jar SwingSet2.jar.
- If the file
user.home/.gtkrc-2.0exists, parse it and continue.
- Determine the user selected theme name (THEMENAME) by way of the desktop property
gnome.net/ThemeNamewhich is determined using XSETTINGS. If this property is null, use
- If the file
user.home/.themes/THEMENAME/gtk-2.0/gtkrcexists parse it and stop.
- If the system property
swing.gtkthemedirexists and the file
swing.gtkthemedir/THEMENAME/gtk-2.0/gtkrcexists, parse it and stop.
- If the system property
swing.gtkthemedirdoesn't exist and the file
/usr/share/themes/THEMENAME/gtk-2.0/gtkrcexists, parse it and stop.
- Lastly if
swing.gtkthemediris defined parse
swing.gtkthemedir/THEMENAME/gtk/gtkrc, otherwise parse
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
bluecurveengines. 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
GTKLookAndFeelwill 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
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
Bluecurvethemes. If we can not locate either of these themes we fall back to our own custom theme. You can use the system property
swing.metacitythemenameto name a particular theme to use, otherwise we will look in
user.dir/.gconf/apps/metacity/general/%gconf.xmlto determine the name of theme and look in
/usr/gnome/share/themes/THEMENAME/metacity-1/metacity-theme-1.xmlfor 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.
One bug worth mentioning:
Copyright © 1993, 2011, Oracle and/or its affiliates. All rights reserved.