Swing Changes Since JavaTM 2 SDK, Standard Edition, v 1.4 |
Project Swing |
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 ofUIManager.getSystemLookAndFeelClassName()
or by explicitly usingcom.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.jarNote 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 propertyswing.defaultlaf
to becom.sun.java.swing.plaf.gtk.GTKLookAndFeel
. In 1.5 we will makeUIManager.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, useDefault
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 fileswing.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 parseswing.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
, andbluecurve
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 ajava.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 theCrux
andBluecurve
themes. If we can not locate either of these themes we fall back to our own custom theme. You can use the system propertyswing.metacitythemename
to name a particular theme to use, otherwise we will look inuser.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.jarGTK+ 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.
One bug worth mentioning:
Copyright © 2002 Sun Microsystems, Inc. All Rights Reserved. Please send comments to: swing-feedback@java.sun.com. This is not a subscription list. |
Java Software |