「Java 2 SDK, Standard Edition, v 1.4でのSwingの変更点と新機能」のドキュメントでは、1.4.*リリースのすべての変更点について説明しています。このドキュメントには、1.4.1と1.4.2に固有の変更点に関するサイトへのリンクが設定してあります。
Swingの場合、このリリースでの主な特徴はバグの修正です。解決済みのバグは以下のとおりです。
フォーカスに関連するバグは以下のとおりです。
ドラッグ・アンド・ドロップに関連するバグは以下のとおりです。
その他のバグは以下のとおりです。
多くのバグが修正されただけでなく、このリリースでは以下のような拡張機能が新たに追加されています。
この変更に関連するバグ追跡レポート: 4679673および4712307。
このリリースでは、JFileChooser
のパフォーマンスの拡張が数多く行われています。状況によっては、JFileChooser
では現在、300倍もパフォーマンスが向上しています。
リリース1.4.2では、Windows XPプラットフォームで実行している場合、デフォルトとして、標準Microsoft Windows XPの外観がサポートされています。このルック・アンド・フィールは、Windows XPオペレーティング・システムを実行しているマシンで、アプリケーションがSwingのWindowsLookAndFeel
クラス(UIManager.getSystemLookAndFeelClassName()
を経由するか、com.sun.java.swing.plaf.windows.WindowsLookAndFeel
を明示的に使用するかのいずれか)を使用している場合に自動的に表示されます。次に、ネイティブ・プラット・フォームのものと一致するルック・アンド・フィールの優先される設定の例を示します。
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
Swingのアプリケーションに旧来のWindowsアプリケーションの外観を指定する場合は、システム・プロパティswing.noxp=true
を使用してXPの外観を変更することができます。これは通常、次のようにコマンド行パラメータを使用して行います。
java -Dswing.noxp=true -jar SwingSet2.jar
swing.noxp
プロパティは、将来のリリースでサポートされなくなる可能性があるので注意してください。
リリース1.4.2では、GTK+2.0に基づいたルック・アンド・フィールが導入されています。このルック・アンド・フィールを取得するには、UIManager.setLookAndFeel("com.sun.java.swing.plaf.gtk.GTKLookAndFeel")
を経由して、または、swing.defaultlaf
システム・プロパティをcom.sun.java.swing.plaf.gtk.GTKLookAndFeel
に定義して明示的に要求する必要があります。次回のリリースでは、適切なときに、UIManager.getSystemLookAndFeelClassName()
がこのルック・アンド・フィールを返すようにする予定です。
GTK+のルック・アンド・フィールは、リソース・ファイルによってカスタマイズできます。SwingのGTK+ルック・アンド・フィールでは、次のアルゴリズムを使用してリソース・ファイルを検索します。
swing.gtkthemefile
が存在する場合は、そのシステム・プロパティを解析して停止します。たとえば、次のようになります。java -Dswing.gtkthemefile=/tmp/customTheme -jar SwingSet2.jar
user.home/.gtkrc-2.0
ファイルが存在する場合は、そのファイルを解析して、先に進みます。gnome.net/ThemeName
により、ユーザーが選択するテーマ名(THEMENAME)を決定します。このプロパティがnullの場合、Default
をTHEMENAMEとして使用します。
user.home/.themes/THEMENAME/gtk-2.0/gtkrc
ファイルが存在する場合は、そのファイルを解析して、停止します。swing.gtkthemedir
があり、swing.gtkthemedir/THEMENAME/gtk-2.0/gtkrc
ファイルが存在する場合は、そのファイルを解析して、停止します。swing.gtkthemedir
がなく、/usr/share/themes/THEMENAME/gtk-2.0/gtkrc
ファイルが存在する場合は、そのファイルを解析して、停止します。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文字列を使用するかの2つの方法でフォントを指定できます。pangoでは、Javaプラットフォームの合成フォントと類似した機能を提供しています。つまり、様々なコード・ポイントの様々なフォントで構成されるフォントを合成する機能です。pangoの合成フォントは、正確にはJavaの合成フォントと一致しないため、GTKLookAndFeel
を使用するSwingのアプリケーションでは、ネイティブのGTK+アプリケーションと厳密には一致しません。現在、この問題に対処する方法を調査中です。1つのオプションとして、pangoのフォント・ファイルをJavaのfont.propertiesファイルと同等のバージョンで置き換える方法があります。さらに現在では、XLFDを無視し、pango文字列(sansをsansserifにマッピングし、monospaceをmonospacedにマッピングした後のもの)を直接java.awt.Font
に渡しています。
GTK+では、MDI (JInternalFrame
)機能を提供していません。また、トップレベル・ウィンドウのテーマ構成を直接サポートすることもしません。このサポートは、ウィンドウ・マネージャに委ねられています。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+リソース・ファイルでは、外観以上に多くのルック・アンド・フィールオプションをカスタマイズすることができます。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ルック・アンド・フィールのバージョンでサポートされる予定です。
Swingの現行のアーキテクチャでGTK+のルック・アンド・フィールを適切にサポートする場合、多くの課題があります。Swingでは、不透明なコンポーネントが「常に」ComponentUIの更新メソッドを通じてそのバックグラウンドをペイントします。GTK+では、エンジンによっては不透明でないコンポーネントがバックグラウンドをペイントする場合があります。GTK+を適切に反映するために、以前は不透明であった多くのコンポーネントが不透明でなくなりました(ComponentUIサブクラスのinstallUIメソッドによる)。さらに、コンポーネントの外観は包含関係の階層に基づいて変更することができるので、コンストラクタの完了後に不透明度が変わる可能性があります。この結果、コンポーネントでsetOpaque()を呼び出すと、予期しない変更が生じる可能性があります。これは次のリリースで修正される予定です。
GTK+はエンジンに呼び出されて、ウィジェットの実際の内容がペイントされる前にボーダー装飾をペイントします。エンジンによっては(特にpixmapエンジンは)この順序によって内容の背景の装飾を正しく描画します。Swingでは、境界は、ウィジェットの内容がペイントされたあとで描画されます。GTKLookAndFeelでは、空白を提供する目的でのみBorderがインストールされ、実際のボーダー装飾の描画はpaintメソッドの一部としてUIが行なっています。このため、GTKLookAndFeelでウィジェットにBorderをインストールすると、望んでいる効果が得られないことがあります。現在はこれに代わる方法を調査しており、次のリリースでより良い解決策が提供される予定です。