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の場合、このリリースでの主な特徴はバグの修正です。 解決済みのバグは以下のとおりです。
フォーカスに関連するバグは以下のとおりです。
- 4632782: JPopupMenuがフォーカスの取得に失敗する
- 4628933: リモート表示アプリケーションが稼動しているMicrosoft Windowsの一部のバージョンで、重量ウィンドウがフォーカスを失う
- 4659800: デフォルト・ボタンがMicrosoft Windowsのルック・アンド・フィールのフォーカスに従う必要がある
- JTabbedPaneおよびフォーカスについての説明
ドラッグ・アンド・ドロップに関連するバグは以下のとおりです。
- 4513715: ドロップしても選択したテキストが上書きされない
- 4513638: RTFEditorKitを使用したJEditorPaneのカット/コピー/ドラッグを修正
- JEditorPaneコンポーネントのインポート/エクスポート動作が変更された
その他のバグは以下のとおりです。
- 4532517: 入力ベリファイアのバグの回避
- 4419964、4668963: Metalのルック・アンド・フィールでMicrosoft Windowsのデスクトップからフォント・サイズを取得できるようになった
- 4615396: ロケールの一部がデスクトップのフォント・サイズだけを受け付ける
- 4668511: JColorChooserのデッドロック
- 4218431: JFileChooserで複数のファイル選択がサポートされているドキュメント
追加リリース、Java 2 SDK, S.E., v1.4.2の変更点
多くのバグが修正されただけでなく、このリリースでは以下のような拡張機能が新たに追加されています。
JFileChooserパフォーマンスの拡張
この変更に関連するバグ追跡レポート: 4679673および4712307。
このリリースでは、JFileChooserのパフォーマンスの拡張が数多く行われています。 状況によっては、JFileChooserでは現在、300倍もパフォーマンスが向上しています。
Windows XPのルック・アンド・フィール
リリース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プロパティは、将来のリリースでサポートされなくなる可能性があるので注意してください。
GTK+のルック・アンド・フィール
リリース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ファイルが存在する場合は、そのファイルを解析して、先に進みます。- XSETTINGSを使用して決定されるデスクトップ・プロパティ
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.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ルック・アンド・フィールのバージョンでサポートされる予定です。
GTKの非互換性
Swingの現行のアーキテクチャでGTK+のルック・アンド・フィールを適切にサポートする場合、多くの課題があります。 Swingでは、不透明なコンポーネントが「常に」ComponentUIの更新メソッドを通じてそのバックグラウンドをペイントします。GTK+では、エンジンによっては不透明でないコンポーネントがバックグラウンドをペイントする場合があります。 GTK+を適切に反映するために、以前は不透明であった多くのコンポーネントが不透明でなくなりました(ComponentUIサブクラスのinstallUIメソッドによる)。 さらに、コンポーネントの外観は包含関係の階層に基づいて変更することができるので、コンストラクタの完了後に不透明度が変わる可能性があります。 この結果、コンポーネントでsetOpaque()を呼び出すと、予期しない変更が生じる可能性があります。 これは次のリリースで修正される予定です。
GTK+はエンジンに呼び出されて、ウィジェットの実際の内容がペイントされる前にボーダー装飾をペイントします。 エンジンによっては(特にpixmapエンジンは)この順序によって内容の背景の装飾を正しく描画します。 Swingでは、境界は、ウィジェットの内容がペイントされたあとで描画されます。 GTKLookAndFeelでは、空白を提供する目的でのみBorderがインストールされ、実際のボーダー装飾の描画はpaintメソッドの一部としてUIが行なっています。 このため、GTKLookAndFeelでウィジェットにBorderをインストールすると、望んでいる効果が得られないことがあります。 現在はこれに代わる方法を調査しており、次のリリースでより良い解決策が提供される予定です。