ローカライズされたテキストの入力

システム環境では、VendorShell ウィジェット・クラスは入力メソッドへのインタフェースを提供するために拡張されます。VendorShell クラスは、ジオメトリ管理で 1 つの子ウィジェットだけをコントロールする一方、入力メソッドへのインタフェースに必要なすべてのコンポーネントが管理できるように、VendorShell クラスに拡張が追加されます。これらのコンポーネントにはステータス領域、プリエディット領域、メイン・ウィンドウ領域があります。

入力メソッドが、ステータス領域かプリエディット領域あるいはその両方を必要とするとき、VendorShell ウィジェットは自動的にステータス領域とプリエディット領域のインスタンスを生成し、それらのジオメトリ・レイアウトを管理します。ステータス領域もプリエディット領域もすべて VendorShell ウィジェットにより内部で管理され、クライアントからはアクセスできません。VendorShell ウィジェットの子としてインスタンスを生成されたウィジェットは、メイン・ウィンドウ領域と呼ばれます。

VendorShell ウィジェットが使用する入力メソッドは XmNinputMethod リソース (たとえば @im=alt) により決定されます。デフォルト値ヌルは、VendorShell が作成されたときに、ロケールに関連付けられたデフォルトの入力メソッドを選択することを示します。このように、ユーザはロケールを設定するか、XmNinputMethod リソースを設定するか、あるいは両方設定することにより、どの入力メソッドが選択されるかに影響を与えることができます。入力メソッド名を決定するために、ロケール名は XmNinputMethod リソースと連結されます。ロケール名はこのリソースに指定してはなりません。XmNinputMethod リソースのモディファイアの名前を @im=modifier 形式の中に指定しなければなりません。modifier は、どの入力メソッドが選択されているかを修飾するのに使う文字列です。

VendorShell ウィジェットは、入力メソッドを共用する複数のウィジェットをサポートできます。しかし、どんな時でもキーボードのフォーカスを持てる (たとえば、キー・プレスのイベントを受信してそれを入力メソッドに送信する) ウィジェットは 1 つだけです。複数のウィジェット (Text ウィジェットなど) をサポートするには、それらのウィジェットが VendorShell ウィジェットの子孫でなければなりません。

VendorShell ウィジェット・クラスは、TransientShell および TopLevelShell ウィジェット・クラスのスーパークラスです。このように、TopLevelShell または Diagshell のインスタンスの生成は、本質的に VendorShell ウィジェット・クラスのインスタンスの生成です。

VendorShell ウィジェットは、子孫の 1 つが XmText[Field] インスタンスである場合のみ入力マネージャとして動作します。XmText[Field] インスタンスが VendorShell ウィジェットの子孫として作成されるとすぐに、VendorShell は現在のロケールによって指示される特定の入力メソッドに必要な領域を作成します。XmText[Field] インスタンスがマップされずにただ作成された場合でも、VendorShell は前述のようなジオメトリ管理の動作を行います。

VendorShell ウィジェットは次のことを行います。

• システムにインストールされたロケールがサポートしているマルチバイト文字の入力および出力を、アプリケーションが処理できるようにします。

• 入力メソッドのインスタンスを、XmIm 参照関数に定義されたとおりに管理します。

• OffTheSpot、OverTheSpot、Root、None のいずれかのモードで、プリエディット領域でのプリエディットをサポートします。ローカライズされたテキストは、フォーカスを変更することにより、複数の Text 子ウィジェット・ツリー内のどの Text 子ウィジェットにも入力できます。

• 子孫ウィジェットのジオメトリ管理を提供します。

ジオメトリ管理

VendorShell ウィジェットは、入力メソッドのユーザ・インタフェース・コンポーネントのジオメトリ管理とフォーカス管理を必要に応じて提供します。ロケールがそれを保証する場合 (たとえばロケールが日本語の EUC (拡張 UNIX コード) ロケールの場合)、VendorShell ウィジェットは、必要なプリエディット領域かステータス領域あるいはその両方のジオメトリを自動的に割り当てて管理します。

現在行われているプリエディットによっては補助領域が必要になります。補助領域が必要な場合は、VendorShell ウィジェットは補助領域の手続きを生成して管理します。通常、VendorShell ウィジェットの子は複数の Text および TextField ウィジェットを管理できるコンテナ・ウィジェット (XmBulletinBoard ウィジェットまたは XmRowColumn ウィジェットなど) であり、ユーザからのマルチバイト文字の入力ができます。このシナリオでは、すべての Text ウィジェットは同一の入力メソッドを共用します。

ステータス領域、プリエディット領域、補助領域にはアプリケーションのプログラマはアクセスできません。たとえば、アプリケーションのプログラマがステータス領域のウィンドウ ID にアクセスすることは想定されていません。それらのコンポーネントは必要に応じて VendorShell ウィジェット・クラスが管理するので、ユーザはそれらのコンポーネントのインスタンスの生成や管理について考える必要はありません。

アプリケーションのプログラマは、VendorShell ウィジェット・クラスの XmNpreedetType リソースを介して、入力メソッドのユーザ・インタフェース・コンポーネントの動作をいくらかコントロールできます。OffTheSpot モードと OverTheSpot モードについては、「入力メソッド」を参照してください。

ジオメトリ管理は、すべての入力メソッドのユーザ・インタフェースのコンポーネントに及びます。アプリケーション・プログラム・ウィンドウ (TopLevelShell ウィジェット) がサイズ変更されると、入力メソッドのユーザ・インタフェースのコンポーネントもそれに応じてサイズ変更され、その中のプリエディットされた文字列は必要に応じて再配置されます。もちろん、シェル・ウィンドウのサイズ変更ポリシーが true であることを想定しています。

VendorShell ウィジェットが作成されるとき、特定の入力メソッドがステータス領域、プリエディット領域、あるいはその両方を必要とする場合、VendorShell のサイズはそれらのコンポーネントが必要とする領域を考慮します。プリエディット領域とステータス領域が必要とする特別な領域は、VendorShell ウィジェットの領域の一部です。それらの領域も、サイズ変更する必要がある場合は VendorShell ウィジェットに管理されます。

それらの領域 (ステータス領域およびプリエディット領域) の潜在的な手続きの作成のために、現在使用されている入力メソッドによって、VendorShell ウィジェット領域のサイズは必ずしも子のサイズにぴったり合うように伸縮する必要はありません。VendorShell ウィジェット領域のサイズは、子のジオメトリとこれらの入力メソッドのユーザ・インタフェース領域のジオメトリの両方が入るように伸縮します。VendorShell ウィジェットと子ウィジェット (メイン・ウィンドウ領域) 間の高さには差があるかもしれません (たとえば 20 ピクセル)。幅のジオメトリは、入力メソッドのユーザ・インタフェースのコンポーネントに影響されません。

まとめると、子に要求されたサイズは可能であれば受け付けられます。VendorShell の実際のサイズは子よりも大きい場合もあります。

VendorShell ウィジェットと子のジオメトリを指定する要求は、互いに矛盾しない限り、または VendorShell ウィジェットのサイズ変更能力の制約内であれば行われます。矛盾する場合は、子のウィジェット・ジオメトリ要求が優先します。たとえば、子ウィジェットのサイズが 100 * 100 に指定された場合、VendorShell のサイズも 100 * 100 に指定されます。子ウィジェットのサイズが 100 * 100 になるのに対して、VendorShell のサイズは結果的に 100 * 120 になります。子ウィジェットのサイズが指定されない場合、独自のサイズ指定を使用する必要があれば VendorShell は子ウィジェットを縮小します。たとえば、VendorShell のサイズが 100 * 100 に指定され、子のサイズは指定されない場合、子ウィジェットのサイズは 100 * 80 になります。VendorShell ウィジェットがサイズ変更を禁止されている場合は、子のジオメトリ要求がどうであっても VendorShell ウィジェットは独自のジオメトリ指定を使用します。

フォーカス管理

多数の文字を使用する言語 (日本語や中国語など) には、ユーザがその言語で対話的に文字を構成できる入力メソッドが必要です。このような言語には、端末のキーボードに適正にマップできる数をはるかに超える文字が存在するからです。

そのような言語で文字を構成する対話的なプロセスをプリエディットといいます。プリエディット自体は入力メソッドによって処理されます。しかし、プリエディットのユーザ・インタフェースはシステム環境により決定されます。入力メソッドとシステム環境の間にインタフェースが存在する必要があります。これは、システム環境の VendorShell ウィジェットを介して実行できます。

図 4-3 は日本語のプリエディットの例を示しています。反転表示された文字列がプリエディット中の文字列です。この文字列は、特定のウィンドウへのフォーカスを与えることにより、異なるウィンドウに移動できます。しかし、プリエディット・セッションは一度に 1 つだけです。

図 4-3 日本語のプリエディットの例

フォーカス管理の例として、TopLevelShell ウィジェット (VendorShell ウィジェットのサブクラス) が、5 つの XmText ウィジェットを子に持つ XmBulletinBoard ウィジェットの子 (メイン・ウィンドウ領域) を持っていると想定します。そのロケールにはプリエディット領域が必要で、OverTheSpot モードが指定されていると想定します。VendorShell ウィジェットは入力メソッドの手続きを 1 つだけ管理するので、プリエディット領域は TopLevelShell ウィジェットの内部で一度に 1 つだけしか実行できません。フォーカスがある Text ウィジェットから他の Text ウィジェットへ移動される場合は、処理中の現在のプリエディット文字列も、現在フォーカスを持っている Text ウィジェットのトップに移動されます。以前の Text ウィジェットへのキー処理は一時的に中断されます。以降の入力メソッドのインタフェース (プリエディット完了時の文字列の送信等) は、フォーカスされた新しい Text ウィジェットに対して行われます。

プリエディットされている文字列は、マウスをクリックするなどの動作でフォーカスの位置に移動できます。

エンド・ユーザがプリエディットを終えてすでに確定した文字列は再変換できません。いったん文字列が構成されると、それは確定されます。文字列を確定するというのは、その文字列がプリエディット領域からクライアントのフォーカス・ポイントへ移動することです。