Input Method Framework仕様
目次
1. フレームワークのアーキテクチャ
次の図は、フレームワークとそのクライアントの全体的な構造を示しています。太線枠の部分は、Java SEプラットフォームの一部としてInput Method Frameworkとともに統合されます。その他の部分は、独立系ソフトウェア・ベンダーが独自に開発して配布できます。
インプット・メソッド・クライアントAPIで定義されているクラスとインタフェースを使うと、テキスト編集コンポーネントで統合テキスト入力ユーザー・インタフェースを実装できます。AWTテキスト・コンポーネントTextAreaとTextFieldは、実装方法によって、オンザスポット編集またはオーバーザスポット編集の機能を提供します。Swingユーザー・インタフェース・ツールキットのテキスト・コンポーネントは、統合テキスト入力ユーザー・インタフェースを提供します。コンテキスト管理は、テキスト編集コンポーネントとインプット・メソッドの間の通信経路を管理します。インプット・メソッド・エンジンSPIには、インプット・メソッド・エンジンおよびインプット・メソッド・アダプタをフレームワークにプラグインするためのインタフェースを定義します。インプット・メソッド・エンジンは、これらのインタフェースを使ってJavaプログラミング言語内に直接実装できます。ホストのインプット・メソッド・マネージャに統合されているネイティブ・インプット・メソッドを使えるように、アダプタは、ネイティブ・インプット・メソッドおよびInput Method Frameworkで使用されるデータ・モデル間で情報を変換し、変換用ウィンドウを表示します。また、Java SpeechまたはInternet-Intranet Input Method Protocol (IIIMP)など、その他の入力システム用のアダプタも、このインタフェースを使って実装できます。
2. クライアント・コンポーネント
Componentクラスのインスタンスは、すべてInput Method Frameworkのクライアントです。フレームワークでは、次の4種類のコンポーネントが識別されます。
- アクティブ・クライアントとは、getInputMethodRequests実装からnull以外の値が返されるコンポーネントのことです。フレームワークは、このコンポーネントでインプット・メソッド・クライアントAPIがアクティブに使われていることを前提としており、InputMethodListenerインタフェースの実装を提供します。このコンポーネントは、インプット・メソッドの情報のイベントおよび要求を処理し、イベントおよび要求に送信された変換テキストを描画します。
- 非クライアントとは、enableInputMethodsメソッドを使ってインプット・メソッドのサポートを無効にしたコンポーネントのことです。
- ピア・クライアントとは、ピア・テキスト・コンポーネントのことで、TextComponentクラスのインスタンスです。ピア・クライアントの動作は実装に依存しており、インプット・メソッドのサポートが制限されることがあります。Windowsでは、ピア・テキスト・コンポーネントはアクティブ・クライアントと同様に動作します。Solarisでは、ピア・テキスト・コンポーネントは、ホストのインプット・メソッドからの入力のみを受け取り、ビロウザスポット入力方式はサポートしていません(下記を参照)。
- パッシブ・クライアントとは、その他すべてのコンポーネントのことです。フレームワークでは、パッシブ・クライアントではインプット・メソッド・クライアントのAPIが使われないことを前提としていますが、インプット・メソッドからのテキスト入力は受け取る必要があります。
これら4種類のコンポーネントは、同じウィンドウに共存させることができます。このため、Input Method Frameworkでは、コンポーネントの機能を決定し、フォーカスがコンポーネント間を移動するときの動作を調整する必要があります。
候補リストの描画、またはインプット・メソッドの動作を制御するユーザー・インタフェース要素の処理は、クライアント・コンポーネントの役割ではありません。プラットフォームの種類により、インプット・メソッド、ホストのインプット・メソッド・マネージャ、またはInput Method Frameworkが、この処理を行います。
インプット・メソッドでは、クライアント・コンポーネント間の違いは考慮されません。インプット・メソッド間の対話は、Input Method Frameworkを介して間接的に行われます。Input Method Frameworkでは、アクティブ・クライアントと同じインタフェースが使われ、違いは内部で処理されます。
3. 入力方式
Input Method Frameworkでは、次の入力方式がサポートされます。
- オンザスポット入力。クライアント・コンポーネントによって、出力先のドキュメントのコンテキストに変換テキストが描画されます。ただし、描画されたテキストは、さらにインプット・メソッドによる変換または確定が必要です。アクティブ・クライアントのデフォルトの入力方式になります。
- ビロウザスポット入力。変換テキストは、別の変換用ウィンドウに表示されます。変換用ウィンドウは、確定されたテキストの挿入ポイントの直下に自動的に位置付けられます。ウィンドウの場所は、ウィンドウが開いた直後に計算され、確定されたテキストがクライアント・コンポーネントに振り分けられるたびに更新されます。ウィンドウが挿入ポイントの下に位置付けられたときに、ウィンドウの一部またはすべてが画面の外に表示された場合は、挿入ポイントの上に移動されます。この入力方式は、後述するように、アクティブ・クライアントの場合に選択されることがあります。
- ルート・ウィンドウ入力。変換テキストは、別の変換用ウィンドウに表示されます。変換用ウィンドウの位置付けは、手動で行います。この入力方式は、パッシブ・クライアントの場合に使われます。
アクティブ・クライアントの場合は、システム・プロパティまたはAWTプロパティ「java.awt.im.style」に基づいて、フレームワークによってオンザスポットまたはビロウザスポット入力から選択されます。システム・プロパティは、エンド・ユーザーがコマンド行から定義します。AWTプロパティは、ローカリゼーション担当者またはシステム管理者が、ローカライズされたawt.propertiesファイルに定義します。両方のプロパティを定義した場合は、システム・プロパティが優先されます。プロパティの値が「below-the-spot」の場合は、ビロウザスポット入力が使用されます。「below-the-spot」以外の場合は、オンザスポット入力が使われます。
ネイティブ・インプット・メソッドを使ったビロウザスポット入力のサポートは、プラットフォームに依存しています。これはWindows上ではサポートされますが、Solaris上ではサポートされません。サポートされていない場合は、オンザスポット入力が代わりに使われます。
ピア・テキスト・コンポーネント(TextComponentクラスのインスタンス)に対して使われる入力方式は、実装に依存しており、前述の方式のいずれでもない場合があります。Windowsの場合は、前述のようにビロウザスポット入力が選択されることがあり、それ以外ではオーバーザスポット入力が使われます。オーバーザスポット入力の場合は、変換テキストは挿入ポイント上に重ねて表示される別のウィンドウに描画されます。Solarisの場合は、入力方式はインプット・メソッドに依存します。
非クライアント・コンポーネントに関係付けられた入力方式はありません。
インプット・メソッドでは、入力方式間の違いは考慮されません。クライアント・コンポーネントとの対話は、Input Method Frameworkを介して間接的に行われます。Input Method Frameworkでは、オンザスポット入力を前提としたインタフェースが使われ、違いは内部で処理されます。
4. インプット・メソッド・エンジンとインプット・メソッド・アダプタ
インプット・メソッド・エンジンSPIを使うと、Javaプログラミング言語でインプット・メソッドを開発することができます。また、Java SpeechまたはInternet-Intranet Input Method Protocolなど、その他の入力システム用のアダプタも、このインタフェースを使って実装できます。SPIについての詳細は、SPIパッケージの仕様を参照してください。
SPIは、ホストのインプット・メソッド・アダプタでも使われます。ホストのインプット・メソッド・アダプタは、Microsoft WindowsのInput Method Manager、MacOSのText Services Manager、SolarisのXIMなど、ホストのインプット・メソッド・マネージャと統合されたネイティブ・インプット・メソッドに接続されています。ホストのインプット・メソッド・アダプタは、Input Method Framework内でのインプット・メソッドの役割を果たし、AWTとInput Method Frameworkの側で使われるデータ・モデルと、ホストのインプット・メソッド・マネージャの側で使われるデータ・モデルの間で、イベントと要求の変換を行います。また、変換用ウィンドウの管理では、入力コンテキストとも連携します。一般に、ホストのインプット・メソッドと対話しているパッシブ・クライアントでは、ホストのインプット・メソッド・マネージャが提供するルート・ウィンドウが使われます。アダプタは特定のインプット・メソッドへの要求をホストに渡しますが、ホストの選択メカニズムを使用してユーザーがインプット・メソッドを選択することもできます。
5. コンテキスト管理
InputContextのインスタンスは、クライアント・コンポーネントとインプット・メソッドの間の通信コンテキストを管理します。入力コンテキストの主な機能は、現在のクライアント・コンポーネントから現在のインプット・メソッドへの接続を維持することです。入力コンテキストは、キー・イベントやマウス・イベントなどの入力イベントをコンポーネントから現在のインプット・メソッドにディスパッチし、インプット・メソッドのイベントをインプット・メソッドからクライアント・コンポーネントにディスパッチします。また、インプット・メソッドからクライアント・コンポーネントへの情報の要求もディスパッチします。
InputContextインスタンスごとに、他の入力コンテキストからは独立した、独自のテキスト入力環境が提供されます。このため、複数の入力操作を同時に行うことができるアプリケーションを作成できます。たとえば、ドキュメントにテキストを入力しているときに、ファイル・ダイアログを開いてファイル名を入力できます。このとき、ドキュメントに入力しているテキストの変換の状態には影響しません。
デフォルトでは、ウィンドウのインスタンスごとに1つのInputContextのインスタンスが作成されて、ウィンドウの包含関係の階層に含まれるすべてのコンポーネントがこの入力コンテキストを共有します。必要に応じて、コンポーネントはプライベートな入力コンテキストを作成できます。独自の入力コンテキストを持たないコンポーネントは、親の入力コンテキストを使います。入力コンテキストには、フォーカスが現在設定されている、現在のクライアント・コンポーネントだけが含まれます。新しいクライアント・コンポーネントに切り替えると、入力コンテキストからendCompositionメソッドが呼び出され、直前のクライアント・コンポーネントの変換用テキストが確定またはキャンセルされます。
入力コンテキストは、クライアント・コンポーネントが使う必要のあるインプット・メソッド・エンジンごとに、インプット・メソッドのインスタンスを作成します。入力コンテキストのインスタンスごとに、独自のインプット・メソッドのインスタンスが作成されます。インスタンスは、入力コンテキストが破棄されるまで残っているので、ウィンドウで入力されたテキストについての情報を保持できます。
また、入力コンテキストは、インプット・メソッドを選択し、変換用ウィンドウを処理します。
インプット・メソッドの選択
入力コンテキストには、現在のインプット・メソッドおよび現在のロケールが含まれます。
Input Method Frameworkでインプット・メソッドおよび入力ロケールを選択する場合、次の2つの方法があります。
- InputContext.selectInputMethodメソッドを使って、特定のロケールがサポートされるインプット・メソッドをアプリケーションから要求する。
- ユーザー・インタフェースを使って、ユーザーがインプット・メソッドを名前で要求し、入力ロケールを指定する。ユーザー・インタフェースから選択しても、現在アクティブな入力コンテキスト以外には影響しない。
フレームワークでは、いずれかの選択方法が優先されることはありません。このため、最後に正常終了した選択方法が、入力コンテキストで使われる現在のインプット・メソッドとなります。要求されたロケールをサポートしているインプット・メソッドが存在しない場合は、selectInputMethodは失敗します。
入力コンテキストは、新しいインプット・メソッドに切り替える前に、古いインプット・メソッドのendCompositionメソッドを呼び出します。入力コンテキストは、古いインプット・メソッドのインスタンスを保持し、同じインプット・メソッドがあとで再度選択されたときに再利用します。
InputContext.selectInputMethodは、インストールされているすべてのインプット・メソッドのInputMethodDescriptor.getAvailableLocalesメソッドを使って、目的のロケールがサポートされているインプット・メソッドを検索します。ユーザーが、目的のロケールのインプット・メソッドをすでにユーザー・インタフェースから選択している場合は、そのインプット・メソッドが選択されます。それ以外のときは、目的のロケールが複数のインプット・メソッドでサポートされている場合、インプット・メソッドは実装に依存して選択されます。
インプット・メソッド選択用のユーザー・インタフェースは、実装に依存しています。使用可能なインプット・メソッドがすべて表示され、ユーザーがそこから選択できなければなりません。インプット・メソッドで複数のロケールがサポートされている場合は、ユーザー・インタフェースから特定の入力ロケールを選択できなければなりません。ホストから入力ロケールを選択するための代替機能が提供される場合は、この機能は省略されます。ライセンス契約者が、各プラットフォーム用のJava Runtime Environmentを開発している場合は、キーボードまたはインプット・メソッドを選択するためのユーザー・インタフェースを、既存のインタフェースと統合することをお薦めします。
Windowsおよび(MotifベースのAWTを使用する) Solarisのユーザー・インタフェースは、3つの部分から構成されます。つまり、Motifの「ウィンドウ」メニューまたはWindowsの「システム」メニューに追加される「入力メソッドの選択」メニュー項目、ユーザー定義の入力方式切替えキー、「入力メソッドの選択」メニュー項目または入力方式切替えキーによって表示されるポップアップ・メニューです。「入力メソッドの選択」メニュー項目は、Java Runtime Environmentで使用可能なインプット・メソッドが複数存在する場合にまたはインプット・メソッドで複数のロケールがサポートされている場合にのみ表示されます(ホストのインプット・メソッド・アダプタは1つのインプット・メソッドとして扱われる)。ポップアップ・メニューには、使用可能なインプット・メソッドが表示され、複数のロケールがサポートされるインプット・メソッドの場合は、サポートされているロケールがサブメニューとして表示されます。ユーザーは、このリストから選択できます。(XベースのAWTを使用する) SolarisおよびLinuxのJREには、「入力メソッドの選択」メニュー項目がありません。つまり、入力方式切替えキーを押したときにのみ、ポップアップ・メニューが表示されます。入力方式切替えキーの定義は、基本キーのコード値の定義と、修飾子の定義の、2つの設定を使用して持続的に保存されます。「修飾子」の設定はオプションです。定義された修飾子のエントリがkeyCodeエントリと一致しない場合、その修飾子エントリは無視されます。次の表にその内容を示します。
|
キー名(文字列) |
値(int) |
|---|---|
| keyCode | 任意のjava.awt.event.KeyEvent.VK_*値(VK_UNDEFINEDを除く) |
| 修飾子 |
java.awt.event.InputEvent.*_MASKの任意の組み合わせ |
JREでは、これらの設定はユーザーの設定ツリー・ノードの/java/awt/im/selectionKeyで最初に検索されます。定義が検出されない場合は、システムの設定ノードの同じパスが検索されます。
変換用ウィンドウ
パッシブ・クライアント、およびビロウザスポット入力を使っているアクティブ・クライアントの場合は、Input Method Frameworkに変換用ウィンドウが提供されます。このウィンドウは、インプット・メソッドによって変換テキストの送信が開始されたときに開き、すべてのテキストが確定されたときに閉じます。現在複数の変換が個別の入力コンテキストを使って行われている場合でも、開かれる変換用ウィンドウは1つだけです。
ビロウザスポット入力の場合は、ウィンドウは、確定されたテキストの挿入ポイントの直下に自動的に位置付けられます。ウィンドウの場所は、ウィンドウが開いた直後に計算され、確定されたテキストがクライアント・コンポーネントに振り分けられるたびに更新されます。ウィンドウが挿入ポイントの下に位置付けられたときに、ウィンドウの一部またはすべてが画面の外に表示された場合は、挿入ポイントの上に移動されます。
6. フレームワークを経由する情報フロー
フレームワークでは、現在のクライアント・コンポーネントと現在のインプット・メソッド間の情報を通信するために、次の2つのメカニズムが提供されます。
- ユーザー・アクションの情報をインプット・メソッドに渡すとき、および入力テキストの変更をコンポーネントに通知するときには、AWTイベントが使われる。このモデルでは、ほかの入力操作と一貫性のあるプログラミング・インタフェースが提供される。ただし、InputMethodEventは通常、コンポーネントのメソッドに同期的にディスパッチされるのに対し、ほかのAWTイベントのディスパッチはイベント・キューを通して非同期にディスパッチされる。
- InputMethodRequestsインタフェースには、クライアント・コンポーネントから情報を要求するときに、インプット・メソッドから呼び出されるメソッドを定義する。この呼出しは、同期的に行われる。
イベントのディスパッチおよびInputMethodRequestsメソッドの呼出しは、入力コンテキストを介して間接的に実行されます。このため、入力コンテキストでは、必要に応じて情報が変換用ウィンドウにリダイレクトされます。変換用ウィンドウでは、アクティブ・クライアントの実装がすべて提供されます。インプット・メソッドでは、常にアクティブ・クライアントとの対話が前提となっています。
以降のセクションでは、Input Method Frameworkを経由するイベント・フロー、およびインプット・メソッドの要求に関連する処理について説明します。クライアント・コンポーネントの種類および選択した入力形式に応じて、4つのイベント・フローを紹介します。これらのイベント・フローでは、インプット・メソッド・エンジンSPIを使って、インプット・メソッドがJavaプログラミング言語で実装されていることを前提としています。ピア・テキスト・コンポーネントまたはネイティブ・インプット・メソッドのイベント・フローは、実装に依存しており、大きく異なるため、ここでは説明しません。
オンザスポット入力を使ったアクティブ・クライアント
KeyEventやMouseEventなどの入力イベントは、InputContextオブジェクトを通して現在のインプット・メソッドに送られます。インプット・メソッドでは、テキスト変換のイベントを使った場合、イベントが使われたことを指定し、コンポーネントに対するインプット・メソッド・イベントを生成します。クライアント・コンポーネントでは、インプット・メソッドから送られてくるInputMethodEventを処理し、変換および確定されたテキストを受け取ることができるよう、InputMethodListenerを登録する必要があります。
インプット・メソッドからのInputMethodRequests呼出しは、クライアント・コンポーネントのgetInputMethodRequestsメソッドから返されたオブジェクトに転送されます。
ビロウザスポット入力を使ったアクティブ・クライアント
KeyEventやMouseEventなどの入力イベントは、InputContextオブジェクトを通して現在のインプット・メソッドに送られます。インプット・メソッドでは、テキスト変換のイベントを使った場合、イベントが使われたことを指定し、インプット・メソッド・イベントを生成します。ビロウザスポット入力が選択されているため、イベントは変換用ウィンドウにリダイレクトされてから処理されます。テキストの一部またはすべてが確定されたときに、変換用ウィンドウによって新しいインプット・メソッド・イベントが生成されます。このイベントには、クライアント・コンポーネントに対して確定されたテキストが保持されています。クライアント・コンポーネントでは、変換用ウィンドウから送られてくるInputMethodEventを処理できるようにInputMethodListenerを登録する必要があります。このとき、InputMethodEventには、確定されたテキストのみが含まれます。
変換テキストの表示に関連するインプット・メソッドから行われたInputMethodRequests呼出し(getTextLocation、getLocationOffset)は、変換用ウィンドウで処理されます。その他のすべての呼出しは、クライアント・コンポーネントのgetInputMethodRequestsメソッドから返されたオブジェクトに転送されます。変換用ウィンドウは、クライアント・コンポーネントのgetTextLocation実装を使用して位置付けされます。
パッシブ・クライアント
KeyEventやMouseEventなどの入力イベントは、InputContextオブジェクトを通して現在のインプット・メソッドに送られます。インプット・メソッドでは、テキスト変換のイベントを使った場合、イベントが使われたことを指定し、インプット・メソッド・イベントを生成します。このイベントは、変換用ウィンドウにリダイレクトされ、処理されます。テキストが確定されると、変換用ウィンドウでは、そのテキストが、クライアントの実際のキー・イベント・リスナーに対するキー・イベントに変換されます。KEY_TYPEDイベントだけが送信されます。
インプット・メソッドからのInputMethodRequests呼出しは、変換用ウィンドウで処理されます。変換テキストの表示に関連する呼出し(getTextLocation、getLocationOffset)は、表示される変換テキストの情報に基づいて処理されます。その他の呼出しは、常に、変換が開始されたばかりで確定テキストが存在しないことを前提として処理されます。変換用ウィンドウには、クライアント・コンポーネントのテキストに対するアクセス権がないためです。
非クライアント
非クライアントのイベントは、入力コンテキストには転送されません。すべてのイベントは、コンポーネントのリスナーに直接転送されます。ここでは、キー・リスナーに転送されています。