Java™ 2 SDK, Standard Edition, v 1.4 からの Swing の変更点

「Java 2 SDK, Standard Edition, v 1.4 での Swing の変更点と新機能」のドキュメントでは、1.4.* リリースのすべての変更点について説明しています。このドキュメントには、1.4.1 と 1.4.2 に固有の変更点に関するサイトへのリンクが設定してあります。

追加リリース、Java 2 SDK, S.E., v1.4.1 の変更点

Swing の場合、このリリースでの主な特徴はバグの修正です。解決済みのバグは以下のとおりです。

フォーカスに関連するバグは以下のとおりです。

ドラッグ&ドロップに関連するバグは以下のとおりです。

その他のバグは以下のとおりです。

追加リリース、Java 2 SDK, S.E., v1.4.2 の変更点

多くのバグが修正されただけでなく、このリリースでは以下のような拡張機能が新たに追加されています。

JFileChooser パフォーマンスの拡張

この変更に関連するバグ追跡レポート:4679673 および 4712307。

このリリースでは、JFileChooser のパフォーマンスの拡張が数多く行われています。状況によっては、JFileChooser では現在、300 倍もパフォーマンスが向上しています。

Windows XP の Look & Feel

リリース 1.4.2 では、Windows XP プラットフォームで実行している場合、デフォルトとして、標準 Microsoft Windows XP の外観がサポートされています。この Look & Feel は、Windows XP オペレーティングシステムを実行しているマシンで、アプリケーションが Swing の WindowsLookAndFeel クラス (UIManager.getSystemLookAndFeelClassName() を経由するか、com.sun.java.swing.plaf.windows.WindowsLookAndFeel を明示的に使用するかのいずれか) を使用している場合に自動的に表示されます。次に、ネイティブプラットフォームのものと一致する Look & Feel の優先される設定の例を示します。

  UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());

Swing のアプリケーションに旧来の Windows アプリケーションの外観を指定する場合は、システムプロパティー swing.noxp=true を使用して XP の外観を変更することができます。これは通常、次のようにコマンド行パラメータを使用して行います。

  java -Dswing.noxp=true -jar SwingSet2.jar

swing.noxp プロパティーは、将来のリリースでサポートされなくなる可能性があるので注意してください。

GTK+ の Look & Feel

リリース 1.4.2 では、GTK+ 2.0 に基づいた Look & Feel が導入されています。この Look & Feel を取得するには、UIManager.setLookAndFeel("com.sun.java.swing.plaf.gtk.GTKLookAndFeel") を経由して、または、swing.defaultlaf システムプロパティーを com.sun.java.swing.plaf.gtk.GTKLookAndFeel に定義して明示的に要求する必要があります。次回のリリースでは、適切なときに、UIManager.getSystemLookAndFeelClassName() がこの Look & Feel を返すようにする予定です。

GTK+ の Look & Feel は、リソースファイルによってカスタマイズできます。Swing の GTK+ Look & Feel では、次のアルゴリズムを使用してリソースファイルを検索します。

システムプロパティーの swing.gtkthemefile が存在する場合は、そのシステムプロパティーを解析して停止します。たとえば、次のようになります。java -Dswing.gtkthemefile=/tmp/customTheme -jar SwingSet2.jar
user.home/.gtkrc-2.0 ファイルが存在する場合は、そのファイルを解析して、先に進みます。
XSETTINGS を使用して決定されるデスクトッププロパティー gnome.net/ThemeName により、ユーザーが選択するテーマ名 (THEMENAME) を決定します。このプロパティーが null の場合、Default を THEMENAME として使用します。
1. user.home/.themes/THEMENAME/gtk-2.0/gtkrc ファイルが存在する場合は、そのファイルを解析して、停止します。
2. システムプロパティーの swing.gtkthemedir があり、swing.gtkthemedir/THEMENAME/gtk-2.0/gtkrc ファイルが存在する場合は、そのファイルを解析して、停止します。
3. システムプロパティーの swing.gtkthemedir がなく、/usr/share/themes/THEMENAME/gtk-2.0/gtkrc ファイルが存在する場合は、そのファイルを解析して、停止します。
4. 最後に、swing.gtkthemedir が定義されている場合は swing.gtkthemedir/THEMENAME/gtk/gtkrc を解析し、定義されていない場合は /usr/share/themes/THEMENAME/gtk/gtkrc を解析します。

GTK+ をカスタマイズする 1 つの方法は、テーマエンジンを使用することです。いくつかのエンジンが存在します。1.4.2 では、Swing は Default、pixmap、および bluecurve エンジンのテーマファイルをサポートしています。現在は、API をオープンにして追加の GTK エンジンを作成できるようにする方法を調査中です。例については、http://www.themes.org を参照してください。

GTK+ では、XLFD を使用するか、pango 文字列を使用してフォントを指定できます。Pango では、Java プラットフォームの合成フォントと類似した機能を提供しています。つまり、さまざまなコードポイントのさまざまなフォントで構成されるフォントを合成する機能です。Pango の合成フォントは、正確には Java の合成フォントと一致しないため、GTKLookAndFeel を使用する Swing のアプリケーションでは、ネイティブの GTK+ アプリケーションと厳密には一致しません。現在、この問題に対処する方法を調査中です。1 つのオプションとして、Pango のフォントファイルを Java の font.properties ファイルと同等のバージョンで置き換える方法があります。さらに現在では、XLFD を無視して、sans を sansserif に、monospace を monospaced にマッピングしたあとに、Pango 文字列を直接 java.awt.Font に渡しています。

GTK+ では、MDI (JInternalFrame) 機能は提供していません。また、最上位のウィンドウのテーマ構成を直接行いません。このサポートは、WindowManager が行います。Swing の MDI クラスについては、Metacity の形式でテーマ構成がサポートされています。現在サポートされているのは、Crux および Bluecurve のテーマだけです。これらのテーマのいずれも検索できない場合、独自のカスタムテーマが実行されます。システムプロパティーの swing.metacitythemename を使って、使用する特定のテーマに名前を付けることができます。そうしない場合は、user.dir/.gconf/apps/metacity/general/%gconf.xml 内を検索してテーマの名前を判定し、/usr/share/themes/THEMENAME/metacity-1/metacity-theme-1.xml または /usr/gnome/share/themes/THEMENAME/metacity-1/metacity-theme-1.xml 内を検索して実際のリソースファイルを探します。次の例では、Swing をトリガーして特定の metacity テーマを使用する方法を示しています。

  java -Dswing.metacitythemename=Bluecurve -jar SwingSet2.jar

GTK+ リソースファイルでは、外観以上に多くの Look & Feel オプションをカスタマイズすることができます。1.4.2 では、プライマリスタイル構成 (fg、bg、base ..)、gtk-font-name、gtk-icon-sizes、ストックアイコン (optionpane 用)、focus-line-width、focus-padding、focus-line-pattern、internal-padding、shadow-type (メニューバー用)、および trough-border がサポートされています。

GTK では、実行中のアプリケーションがテーマの変更を感知して自動的に UI を更新できるメカニズムを提供しています。これは、今後の Swing の GTK Look & Feel のバージョンでサポートされる予定です。

GTK の非互換性

Swing の現行のアーキテクチャーで GTK+ Look & Feel を適切にサポートする場合、多くの課題があります。Swing では、不透明なコンポーネントが「常に」ComponentUI のアップデートメソッドを通じてそのバックグランドをペイントします。GTK+ では、エンジンによっては、不透明でないコンポーネントがバックラウンドをペイントする場合があります。GTK+ を適切に反映するために、以前は不透明であった多くのコンポーネントが不透明でなくなりました (ComponentUI サブクラスの installUI メソッドによる)。さらに、コンポーネントの外観は包含関係の階層に基づいて変更することができるので、コンストラクタの完了後に不透明度が変わる可能性があります。この結果、コンポーネントで setOpaque() を呼び出すと、予期しない変更が生じる可能性があります。これは次のリリースで修正されます。

GTK+ はエンジンに呼び出されて、ウィジェットの実際の内容がペイントされる前にボーダー装飾をペイントします。エンジンによっては (特に pixmap エンジンは) この順序によって内容の背景の装飾を正しく描画します。Swing では、境界は、ウィジェットの内容がペイントされたあとで描画されます。GTKLookAndFeel では、空白を提供する目的でのみ Border がインストールされ、実際のボーダー装飾の描画は paint メソッドの一部として UI が行なっています。このため、GTKLookAndFeel でウィジェットに Border をインストールすると、望んでいる効果が得られないことがあります。現在はこれに代わる方法を調査しており、次のリリースでより良い解決策が提供される予定です。

1.4.2 のバグ

注意を要するバグは以下のとおりです。

4759306: JColorChooser.setPreviewPanel が古いパネルを削除しない。

連絡先