org.eclipse.jface.resource パッケージは、プラグインによる、フォントおよびアイコンなどの UI リソースの管理を支援するクラスを定義しています。
ワークベンチ拡張ポイントの多くで、プラグインは、ワークベンチにアイコンを表示してその機能を示すことができます。 GUI のオペレーティング・システムは、メモリー内で一度にサポートするイメージまたはフォントの数を制限しているので、 プラグインの UI リソースの管理には注意が必要であり、場合によっては、 それらをウィジェット間で共用しなければならないこともあります。
すでに、readme ツール・プラグインでアイコンへの参照をいくつか見てきました。 そのアイコンの一部は、plugin.xml のマークアップで指定されています。
<extension point="org.eclipse.ui.views"> <category id="org.eclipse.ui.examples.readmetool" name="%Views.category"> </category> <view id="org.eclipse.ui.examples.readmetool.views.SectionsView" name="%Views.ReadmeSections" icon="icons/view16/sections.gif" category="org.eclipse.ui.examples.readmetool" class="org.eclipse.ui.examples.readmetool.ReadmeSectionsView"> </view> </extension>
また、イメージを即時に記述するコードも見ました。 以下に示すものは、readme ツールの ReadmeEditorActionBarContributor からのものです。
public ReadmeEditorActionBarContributor() { ... action1 = new EditorAction(MessageUtil.getString("Editor_Action1")); action1.setToolTipText(MessageUtil.getString("Readme_Editor_Action1")); action1.setDisabledImageDescriptor(ReadmeImages.EDITOR_ACTION1_IMAGE_DISABLE); action1.setImageDescriptor(ReadmeImages.EDITOR_ACTION1_IMAGE_ENABLE); ...
JFace は、対応するプラットフォームのグラフィックス・オブジェクトが作成および廃棄される時点を気にすることなく、 プラグインがそのアイコンとフォントを管理できるようにする、基本サポート・クラスを提供しています。 これらのサポート・クラスは、上記のように、プラグインによって直接使用されます。 あるいは、ワークベンチがこれらのクラスを使用して、拡張ポイントのマークアップで記述されているイメージを取得する場合は、 間接的に使用されます。
SWT の Image クラスは、 オペレーティング・システムの観点からイメージを表します。 ほとんどの GUI オペレーティング・システムは、一度に開くことのできるイメージの数を制限しているので、 それらを作成する場合は、プラグインでは慎重さが要求され、 イメージを使い終わったら適切にそれを廃棄するようにしなければなりません。 SWT のイメージではなく、JFace の ImageDescriptor および ImageRegistry クラスを 使用することにより、プラグインは、通常、これらのイメージを直接作成、管理、および廃棄することを回避することができます。
ImageDescriptor クラスは、 軽量のイメージ記述として使用することができます。 このクラスは、イメージを作成するために必要なすべてのもの、例えばイメージを取得できる URL や ファイル名を指定します。 ImageDescriptors は、 createImage() メソッドを使用して明示的に要求されるまでは、実際のプラットフォーム・イメージを割り振りません。
コードがすべてのアイコンを 1 つの場所で定義し、それらを必要に応じて割り振るようにコードが構造化されている場合には、 イメージ・ディスクリプターが最も良い方法です。 イメージ・ディスクリプターは、OS のリソースを気にすることなく、いつでも作成することができ、 リソースをすべて初期化コードで作成する場合には役立ちます。
ImageRegistry クラスは、 指定されたイメージのリストを保管するために使用されます。 クライアントは、イメージ・ディスクリプターまたは SWT イメージをリストに直接追加することができます。 イメージがレジストリーから名前で要求されると、レジストリーは、それが作成されている場合は、そのイメージを戻します。 あるいは、ディスクリプターからそれを作成します。 これにより、レジストリーのクライアントは、イメージを共用することができます。
レジストリーに追加された、またはレジストリーから取り出されたイメージは、クライアントが廃棄することはできません。 イメージは複数のクライアントに共用されているので、イメージの廃棄はレジストリーが行います。 レジストリーは、プラットフォーム の GUI システムがシャットダウンするときにイメージを廃棄します。
可能な場合は、プラグインの UI オブジェクトは、plugin.xml ファイルで指定してください。 ワークベンチ拡張ポイントの多くは、アイコン・ファイルの構成パラメーターを含んでいます。 plugin.xml の拡張追加項目にアイコンを定義して、イメージ管理戦略をプラットフォームに任せます。 アイコンは、通常、プラグインのディレクトリーに保管されるので、これにより、アイコンを指定し、 ファイルをすべて 1 つの場所で管理することができます。
アイコンを拡張追加項目のパーツとして指定することができない場合にのみ、別のパターンを考える必要があります。
イメージが頻繁に使用されることがなく、共用されていない場合には、イメージを明示的に作成することが最良の戦略です。 イメージは SWT に直接作成し、使用後は廃棄することができます。
また、イメージは ImageDescriptor を 使用して createImage() メソッドを呼び出しても明示的に作成することができます。 最初の場合のように、イメージに対する dispose() メソッドは、そのイメージが不要になった後で呼び出さなければなりません。 例えば、ダイアログが開くときにイメージが作成される場合は、 そのダイアログが閉じるときにそのイメージを廃棄しなければなりません。
イメージがプラグインで頻繁に使用され、UI 内の多くの異なるオブジェクト間で共用される場合は、 イメージ・ディスクリプターを ImageRegistry に 登録すると役立ちます。 レジストリー内のイメージは、同じ名前によりイメージを照会するオブジェクトで共用されます。 レジストリー内のイメージは、他のオブジェクトに共用されているので、廃棄してはいけません。
イメージが、プラグインの存続期間の間、頻繁に使用され、多くのオブジェクトに共用されている場合は、 イメージをイメージ・レジストリーに追加することが最良の戦略です。 レジストリーを使用する際の欠点は、 レジストリー内のイメージは、GUI システムがシャットダウンするまで廃棄されないことです。 一度に開くことができるプラットフォーム (SWT) イメージの数には制限があるので、 プラグインでは、レジストリーに多くのアイコンを登録しすぎないよう注意する必要があります。
クラス AbstractUIPlugin には、 プラグイン全体のイメージ・レジストリーを作成するためのプロトコルが組み込まれています。
アイコンを使用して頻繁に特定のビューアー内に項目を表示する場合、 ラベル・プロバイダーを使用してビューアー内の類似の項目間でアイコンを共用することができます。 ビューアー内の任意のオブジェクトのイメージを戻すことはラベル・プロバイダーが行うので、 ラベル・プロバイダーは、イメージの作成と、ビューアー内のオブジェクト間でのイメージの共用を制御することができます。
ラベル・プロバイダーは、以前に説明した手法を使用してイメージを作成することができます。 LabelProvider サブクラス内の getImage() の各種インプリメンテーションを見ると、 オブジェクトの単一アイコンのキャッシュ、およびタイプごとのイメージ・テーブルの保守を含む、 さまざまなアプローチがあることがわかります。 ラベル・プロバイダーによって作成されたイメージは、 プロバイダーの dispose() メソッド (これはビューアーが廃棄されるときに呼び出されます) で廃棄しなければなりません。
ラベル・プロバイダーを使用することにより、明示的作成とイメージ・レジストリーの間で妥協を図ることができます。 これにより、イメージ・レジストリーのようにアイコンの共用が促されますが、 実際のイメージの作成と廃棄のコントロールを維持することもできます。
プラグインを細かく調整する場合には、これらさまざまなイメージ作成パターンをすべて試すことが一般的です。 イメージ作成に関する意思決定を別個のクラスに分離し、 すべてのクライアントに、クラスを使用してすべてのイメージを取得するように指示すると役立ちます。 これにより、プラグインの実際のパフォーマンス特性を反映するように、作成の順序を調整することができます。
フォントは、プラットフォームのオペレーティング・システム内で制限されるもう 1 つのリソースです。 作成と廃棄の問題はフォントの場合もイメージと同様で、速度とスペースの間で同様のトレードオフが要求されます。 通常、フォントは、プラットフォームに依存するフォント名を使用してフォントを要求することにより、SWT 内に割り振られます。
FontRegistry クラスは、 フォント・テーブルをフォントの名前で保持します。 このクラスは、フォントの割り振りと廃棄を管理します。
通常、プラグインは、フォントの割り振り、またはプラットフォーム固有の名前を使用したフォント記述を避けなければなりません。 フォント・レジストリーは JFace 内で内部的に使用されますが、通常、プラグインでは使用されません。 共通フォントにアクセスするには、 JFaceResources クラスを 使用する必要があります。
設定ページでアプリケーションのフォントの優先設定をユーザーに指定させることはきわめて一般的なことです。 この場合、FontFieldEditor を 使用してユーザーからフォント名を取得する必要があり、 FontRegistry を使用して フォントを保持することができます。 FontFieldEditor は、 設定ページでのみ使用されます。
クラス JFaceResources は、 共通プラットフォームのフォントとイメージへのアクセスをコントロールします。 このクラスは、指定されたフォントとイメージをクライアントが共有できるように、 内部のフォント・レジストリーとイメージ・レジストリーを維持します。
要求された場合にイメージを共用するために、ワークベンチおよびその他のプラグインで使用される手法は数多くあります。 JFaceResources イメージ・レジストリーは、ワークベンチおよびプラグイン・コードでは広く使用されているものではありません。
フォントの使い方はさらに簡単です。ワークベンチおよびプラグインは、 JFaceResources クラスを 使用して論理名でフォントを要求します。 getDialogFont() および getDefaultFont() などのメソッドは、 プラグインがその UI で必要なフォントを使用できるようにするために提供されています。