出典: Uimwikija

tkng氏が書いたGlossaryに続くスレッドから転載。

目次 1 input method broker 2 input method framework 3 input method toolkit 4 input style 5 protocol flow 6 segment 7 コンテキスト 8 ブリッジ 9 プラグイン 10 ヘルパー 11 ホットキー 12 モジュール 12.1 Anthy 12.2 m17nlib 12.3 regexp 13 候補 14 入力コンテキスト 15 入力方式 16 確定 17 編集領域

[編集] input method broker

アプリ・変換エンジン間の仲介部。

[編集] input method framework

[編集] input method toolkit

入力方式構築用ライブラリ部。

[編集] input style

• root window
• off the spot
• on the spot
• over the spot

[編集] protocol flow

• full synchronous method
• on demand synchronous method

[編集] segment

uimでは「segment」は分節された文の部分をいう。Anthyでは、変換時の編集領域はひとつ以上のsegmentからなり、各segmentは一つの句からなる。segmentはsegmentごとの処理の単位にもなる。

[編集] コンテキスト

コンテキスト(context)は入力の単位である。入力コンテキストと呼ぶこともある。通常、テキストウィジェット一つにコンテキストは一つである。しかし、アプリケーションによっては、複数のテキストウィジェットが一つの入力コンテキストを共有することもある(例えばMozilla)。

[編集] ブリッジ

ブリッジ(bridge)はアプリケーションとuimの繋ぎのコードである。uimには沢山のブリッジがある。

• GTK+ブリッジ (GTK+ immodule)
• Qtブリッジ (Qt immodule)
• XIMブリッジ (uim-xim)
• Consoleブリッジ (uim-fep)
• Emacsブリッジ (uim.el)
• Macブリッジ (MacUIM)

[編集] プラグイン

「プラグイン(plugin)」はuimのSchemeインタプリタをCで拡張するための仕組みで、主にAnthyのような変換ソフトとuimの繋ぎのコードを書くのに使われる。

http://lists.freedesktop.org/archives/uim/2005-August/001316.html

プラグインという言葉は多くの場合「アプリケーションの拡張機能で、単一のオブジェクトファイルからなるもの」を指すことが多いので、 uim用のfoo.soのようなものは、混乱を避けるためにもプラグイン以外の名前で呼んだ方がいいと思う。

また、後で述べるが、uimの拡張機能を有効にするのに複数のファイルが必要になることもあり、これも既存のプラグインの概念と衝突する。

[編集] ヘルパー

ヘルパー(helper)はuimの暗黒面で、次のような意味で使われている言葉である。

1. プロセス間通信に関するもの
2. coreでもブリッジでもないもの

この二つは混同されるべきではないし、「ヘルパー」という名前も直感的ではない。

そこで、この単語をできるだけ使わないことに決めた。例えば、0.5 系列ではプロセス間通信に関する部分にはmessage busという新しい名前をつけるつもりだ。

[編集] ホットキー

[編集] モジュール

実際の入力と変換を扱う部分をこう呼ぼうと考えたこともあったが、この表現は誤解を招きそうなので、この言葉に明確な定義を与えないことにした。

http://lists.freedesktop.org/archives/uim/2005-August/001316.html

詳しくは後で考えるとして、今はこのようなものだと考えている。

• 単位ごとにインストール・アンインストール、有効・無効にできるコードのまとまり
• モジュール(module)には0個以上の任意の入力方式が含まれる

これを踏まえて以下の例を見て欲しい。

[編集] Anthy

anthyモジュールは三つのファイルからなり、モジュールを有効にすると、副作用としてregister-imを一度呼ぶ。

• anthy/anthy.so
• anthy/anthy.scm
• anthy/anthy-custom.scm

[編集] m17nlib

m17nlibモジュールも三つのファイルからなるが、このモジュール一つを有効にするとregister-imは複数回呼ばれる。

• m17nlib/m17nlib.so
• m17nlib/m17nlib.scm
• m17nlib/m17nlib-custom.scm

[編集] regexp

regexpモジュールは入力方式を含まないが、これも完全なモジュールである。一つのファイルからなり、有効にすると普通の関数が定義される。

• regexp/regexp.so

[編集] 候補

多くの場合、編集領域一つに対して変換候補は複数ある。例えば日本語では、最初にひらがなを入力し次にそれを漢字に変換する。このとき、たいていは複数の候補から一つを選ばなければならない。このような場面で「候補(candidate)」を使う。

厳密に言えば、「変換」候補である必要はない。例えば、PRIMEでは、候補は変換ではなく予測の結果になる。

[編集] 入力コンテキスト

「入力コンテキスト(input context)」は入力の単位である。「コンテキスト」と略すこともある。

[編集] 入力方式

1. キーボードから直接入力できない文字列を入力するソフトウェア
2. uim の標準インタフェース上につくられたモジュールで、(キー入力)イベントを何らかのテキストに変換するもの

[編集] 確定

実際に入力される文字列について入力コンテキストが決定すると、libuimはアプリケーションに「こういう文字列が入力された」と伝える。

この動作を「確定(commit)」と呼ぶ。確定された文字列は最終的な「編集領域」の文字列とは異なることが多い。二つの文字列の等価性についてはいかなる仮定もおくべきではない。

[編集] 編集領域

「編集領域(preedit)」は、まだアプリケーションに入力されていない文字列をいい、ユーザーに入力コンテキストの状態を教える。o-umlautを入力する場合、「Multi_key o "」のようなキー列を入力する。「o」を入力した時点では何を入力するか決定できない(「o」のあとに「'」がきたらo-accuteが入力され、「`」がきた場合はo-graveが入力される)。

多くの場合、編集領域は下線のついた背景が反転した状態でカーソル位置に表示される。

編集領域は複数の文字からなることがあることにも注意。

「前編集」や「事前編集」と呼ばれることもある。