Input Method Framework 仕様

目次

  1. フレームワークのアーキテクチャー
  2. クライアントコンポーネント
  3. 入力方式
  4. インプットメソッドエンジンとインプットメソッドアダプタ
  5. コンテキスト管理
  6. フレームワークを経由する情報フロー

1. フレームワークのアーキテクチャー

次の図は、フレームワークとそのクライアントの全体的な構造を示しています。太線枠の部分は、Java 2 プラットフォームの一部として Input Method Framework とともに統合されます。その他の部分は、独立系ソフトウェアベンダーが独自に開発して配布できます。

以後の文章で、この図について説明しています

インプットメソッドクライアント API で定義されているクラスとインタフェースを使うと、テキスト編集コンポーネントで統合テキスト入力ユーザーインタフェースを実装できます。AWT テキストコンポーネント TextAreaTextField は、実装方法によって、オンザスポット編集またはオーバーザスポット編集の機能を提供します。Swing ユーザーインタフェースツールキットのテキストコンポーネントは、統合テキスト入力ユーザーインタフェースを提供します。コンテキスト管理は、テキスト編集コンポーネントとインプットメソッドの間の通信経路を管理します。インプットメソッドエンジン SPI には、インプットメソッドエンジンおよびインプットメソッドアダプタをフレームワークにプラグインするためのインタフェースを定義します。インプットメソッドエンジンは、これらのインタフェースを使って Java プログラミング言語内に直接実装できます。ホストのインプットメソッドマネージャーに統合されているネイティブインプットメソッドを使えるように、アダプタは、ネイティブインプットメソッドおよび Input Method Framework で使用されるデータモデル間で情報を変換し、変換用ウィンドウを表示します。また、Java Speech または Internet-Intranet Input Method Protocol (IIIMP) など、その他の入力システム用のアダプタも、このインタフェースを使って実装できます。


2. クライアントコンポーネント

Component クラスのインスタンスは、すべて Input Method Framework のクライアントです。フレームワークでは、次の 4 種類のコンポーネントが識別されます。

これら 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」以外の場合は、オンザスポット入力が使われます。

ネイティブインプットメソッドを使ったビロウザスポット入力のサポートは、プラットフォームに依存しています。Sun の Java 2 Runtime Environment の場合は、Windows 上ではサポートされますが、Solaris 上ではサポートされません。サポートされていない場合は、オンザスポット入力が代わりに使われます。

ピアテキストコンポーネント (TextComponent クラスのインスタンス) に対して使われる入力方式は、実装に依存しており、上記の方式のいずれでもない場合があります。Sun の Windows 用 Java 2 Runtime Environment の場合は、ビロウザスポット入力が選択されます。それ以外の場合は、オーバーザスポット入力が使われます。オーバーザスポット入力の場合は、変換テキストは挿入ポイント上に重ねて表示される別のウィンドウに描画されます。Sun の Solaris 用 Java 2 Runtime Environment の場合は、入力方式はインプットメソッドに依存します。

非クライアントコンポーネントに関係付けられた入力方式はありません。

インプットメソッドでは、入力方式間の違いは考慮されません。クライアントコンポーネント間の対話は、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 つの方法があります。

フレームワークでは、いずれかの選択方法が優先されることはありません。このため、最後に正常終了した選択方法が、入力コンテキストで使われる現在のインプットメソッドとなります。要求されたロケールをサポートしているインプットメソッドが存在しない場合は、selectInputMethod は失敗します。

入力コンテキストは、新しいインプットメソッドに切り替える前に、古いインプットメソッドの endComposition メソッドを呼び出します。入力コンテキストは、古いインプットメソッドのインスタンスを保持し、同じインプットメソッドがあとで再度選択されたときに再利用します。

InputContext.selectInputMethod は、インストールされているすべてのインプットメソッドの InputMethodDescriptor.getAvailableLocales メソッドを使って、目的のロケールがサポートされているインプットメソッドを検索します。ユーザーが、目的のロケールのインプットメソッドをすでにユーザーインタフェースから選択している場合は、そのインプットメソッドが選択されます。それ以外のときは、目的のロケールが複数のインプットメソッドでサポートされている場合、インプットメソッドは実装に依存して選択されます。

インプットメソッド選択用のユーザーインタフェースは、実装に依存しています。使用可能なインプットメソッドがすべて表示され、ユーザーがそこから選択できなければなりません。インプットメソッドで複数のロケールがサポートされている場合は、ユーザーインタフェースから特定の入力ロケールを選択できなければなりません。ホストから入力ロケールを選択するための代替機能が提供される場合は、この機能は省略されます。ライセンス契約者が、各プラットフォーム用の Java Runtime Environment を開発している場合は、キーボードまたはインプットメソッドを選択するためのユーザーインタフェースを、既存のインタフェースと統合することをお勧めします。

Sun の Windows 用および (Motif ベースの AWT を使用する) Solaris 用の Java 2 Runtime Environment のユーザーインタフェースは、3 つの部分から構成されます。つまり、Motif の「ウィンドウ」メニューまたは Windows の「システム」メニューに追加される「入力方式の切り替え」メニュー項目、ユーザー定義の入力方式切り替えキー、「入力方式の切り替え」メニュー項目または入力方式切り替えキーによって表示されるポップアップメニューです。「入力方式の切り替え」メニュー項目は、Java Runtime Environment で使用可能なインプットメソッドが複数存在する場合に、またはインプットメソッドで複数のロケールがサポートされている場合にだけ表示されます (ホストのインプットメソッドアダプタは 1 つのインプットメソッドとして扱われる)。ポップアップメニューには、使用可能なインプットメソッドが表示され、複数のロケールがサポートされるインプットメソッドの場合は、サポートされているロケールがサブメニューとして表示されます。ユーザーは、このリストから選択することができます。Sun の (X ベースの AWT を使用する) Solaris および Linux 用 Java 2 Runtime Environment には、「入力方式の切り替え」メニュー項目がありません。つまり、入力方式切り替えキーを押したときにだけ、ポップアップメニューが表示されます。入力方式切り替えキーの定義は、基本キーのコード値の定義と、修飾子の定義の、2 つの設定を使って持続的に保存されます。「修飾子」の設定はオプションです。定義された修飾子のエントリが keyCode エントリと一致しない場合、その修飾子エントリは無視されます。次の表にその内容を示します。

キー名 (文字列)

値 (int)

keyCode 任意の java.awt.event.KeyEvent.VK_* 値 (VK_UNDEFINED を除く)
修飾子

java.awt.event.InputEvent.*_MASK の任意の組み合わせ

Java 2 Runtime では、これらの設定はユーザーの設定ツリーノードの /java/awt/im/selectionKey で最初に検索されます。定義が検出されない場合は、システムの設定ノードの同じパスが検索されます。

変換用ウィンドウ

パッシブクライアント、およびビロウザスポット入力を使っているアクティブクライアントの場合は、Input Method Framework に変換用ウィンドウが提供されます。このウィンドウは、インプットメソッドによって変換テキストの送信が開始されたときに開き、すべてのテキストが確定されたときに閉じます。現在複数の変換が個別の入力コンテキストを使って行われている場合でも、開かれる変換用ウィンドウは 1 つだけです。

ビロウザスポット入力の場合は、ウィンドウは、確定されたテキストの挿入ポイントの直下に自動的に位置付けられます。ウィンドウの場所は、ウィンドウが開いた直後に計算され、確定されたテキストがクライアントコンポーネントに振り分けられるたびに更新されます。ウィンドウが挿入ポイントの下に位置付けられたときに、ウィンドウの一部またはすべてが画面の外に表示された場合は、挿入ポイントの上に移動されます。


6. フレームワークを経由する情報フロー

フレームワークでは、現在のクライアントコンポーネントと現在のインプットメソッド間の情報を通信するために、次の 2 つのメカニズムが提供されます。

InputMethodRequests メソッドのディスパッチおよび呼び出しを行うイベントは、入力コンテキストを介して間接的に実行されます。このため、入力コンテキストでは、必要に応じて情報が変換用ウィンドウにリダイレクトされます。変換用ウィンドウでは、アクティブクライアントの実装がすべて提供されます。インプットメソッドでは、常にアクティブクライアントとの対話が前提となっています。

以降のセクションでは、Input Method Framework を経由するイベントフロー、およびインプットメソッドの要求に関連する処理について説明します。クライアントコンポーネントの種類および選択した入力形式に応じて、4 つのイベントフローを紹介します。これらのイベントフローでは、インプットメソッドエンジン SPI を使って、インプットメソッドが Java プログラミング言語で実装されていることを前提としています。ピアテキストコンポーネントまたはネイティブインプットメソッドのイベントフローは、実装に依存しており、大きく異なるため、ここでは説明しません。

オンザスポット入力を使ったアクティブクライアント

以後の文章で、この図について説明しています

KeyEventMouseEvent などの入力イベントは、InputContext オブジェクトを通して現在のインプットメソッドに送られます。インプットメソッドでは、テキスト変換のイベントを使った場合、イベントが使われたことを指定し、コンポーネントに対するインプットメソッドイベントを生成します。クライアントコンポーネントでは、インプットメソッドから送られてくる InputMethodEvent を処理し、変換および確定されたテキストを受け取ることができるよう、InputMethodListener を登録する必要があります。

インプットメソッドからの InputMethodRequests 呼び出しは、クライアントコンポーネントの getInputMethodRequests メソッドから返されたオブジェクトに転送されます。

ビロウザスポット入力を使ったアクティブクライアント

以後の文章で、この図について説明しています

KeyEventMouseEvent などの入力イベントは、InputContext オブジェクトを通して現在のインプットメソッドに送られます。インプットメソッドでは、テキスト変換のイベントを使った場合、イベントが使われたことを指定し、インプットメソッドイベントを生成します。ビロウザスポット入力が選択されているため、イベントは変換用ウィンドウにリダイレクトされてから処理されます。テキストの一部またはすべてが確定されたときに、変換用ウィンドウによって新しいインプットメソッドイベントが生成されます。このイベントには、クライアントコンポーネントに対して確定されたテキストが保持されています。クライアントコンポーネントでは、変換用ウィンドウから送られてくる InputMethodEvent を処理できるように InputMethodListener を登録する必要があります。このとき、InputMethodEvent には、確定されたテキストだけが含まれます。

変換テキストの表示に関連するインプットメソッドから行われた InputMethodRequests 呼び出し (getTextLocationgetLocationOffset) は、変換用ウィンドウで処理されます。その他のすべての呼び出しは、クライアントコンポーネントの getInputMethodRequests メソッドから返されたオブジェクトに転送されます。変換用ウィンドウは、クライアントコンポーネントの getTextLocation 実装を使って位置付けされます。

パッシブクライアント

以後の文章で、この図について説明しています

KeyEventMouseEvent などの入力イベントは、InputContext オブジェクトを通して現在のインプットメソッドに送られます。インプットメソッドでは、テキスト変換のイベントを使った場合、イベントが使われたことを指定し、インプットメソッドイベントを生成します。このイベントは、変換用ウィンドウにリダイレクトされ、処理されます。テキストが確定されると、変換用ウィンドウでは、そのテキストが、クライアントの実際のキーイベントリスナーに対するキーイベントに変換されます。KEY_TYPED イベントだけが送信されます。

インプットメソッドからの InputMethodRequests 呼び出しは、変換用ウィンドウで処理されます。変換テキストの表示に関連する呼び出し (getTextLocationgetLocationOffset) は、表示される変換テキストの情報に基づいて処理されます。その他の呼び出しは、常に、変換が開始されたばかりで確定テキストが存在しないことを前提として処理されます。変換用ウィンドウには、クライアントコンポーネントのテキストに対するアクセス権がないためです。

非クライアント

以後の文章で、この図について説明しています

非クライアントのイベントは、入力コンテキストには転送されません。すべてのイベントは、コンポーネントのリスナーに直接転送されます。ここでは、キーリスナーに転送されています。


Copyright © 1993, 2013, Oracle and/or its affiliates. All rights reserved.