-
Notifications
You must be signed in to change notification settings - Fork 0
ComposerFramework
= コンポーザフレームワーク =
What's going on: the composer framework (和訳版)より転載。
What's going on: the composer framework
composerフレームワークとは私によって完全に再構築された次世代uimの中核アー キテクチャです。
それは数々のアーキテクチャ的問題点を解決し、入力メソッドの開発を簡単にし、 入力メソッド全体をいじるのではなく再利用可能なコンポーネントの開発による機 能強化を可能にし、プラットフォーム固有の使いやすいIM環境を構築するために適 切に分離されたコンポーネントを提供し、柔軟なIMカスタマイズを可能にします。
このフレームワークそれ自身はユーザレベルIM環境や操作体系についてきまったポ リシーを仮定しません。それらは上のレイヤの問題であって、このフレームワーク がすべき事は適切に責任の分離された再利用可能なコンポーネントを提供する事に よって、どんなシステム構成をも可能にする事です。「GUIツールキット」と「デ スクトップ環境」になぞらえて、このフレームワークを「IMツールキット」と呼び、 「上のレイヤ」を「IM環境」と呼ぶと、このフレームワークの責任範囲について理 解する助けになるかもしれません。
もちろん、「上のレイヤ」はuimの重要な一部分です。私はこのレイヤ分割がプラッ トフォーム固有のIM環境を開発するのを簡単にすると信じています。
このフレームワークは別ブランチ(composerブランチ)にて開発中です。
-
UNIXデスクトップ中心主義の一枚岩的機構群
- モジュール(プラグイン)管理
- 固定流儀の入力コンテキスト生成
- 固定流儀の入力コンテキスト管理
- 固定流儀のIM切り換え方式
- ロケールを認識するIM選出
-
複雑すぎる入力コンテキスト管理方式
- 入力コンテキスト生成処理と、そのインスタンス表現それ自身はCとSchemeに分散した数々の機構に関わっています。それゆえに私たちは入力コンテキストをSchemeから簡単に生成して使う事ができません
-
不十分な責任の分離と再利用性
- あるコードは、他のコード修正の際の意図しない責任侵害によって容易に壊れます
- コピー&ペーストされたあふれるコード群が進歩を阻害しています
- コピー&ペーストされたコードの膨張は、それが黒魔術の物体になってしまう前に阻止して健康を回復するべきです
これらの問題への解はコードで語られます。
-
composer
- composerのインスタンスは、ほぼ入力コンテキストに相当します
- composerはpolymorphicな一揃えのメソッドを提供します
- composerインスタンスはその所有者からのgetterメソッド呼び出しに応じて、それが持つ現在構成中のテキストを返します
- composerインスタンス群は、個々のノードがcomposerインスタンスであるツリーとして組織する事ができます
- そのツリー内のcomposerインスタンスは、子のcomposerインスタンス群のテキスト片を固有の規則に従って自分自身のテキストとしてマージします
- composer APIのCバインディングが将来提供されるでしょうが、Cで書かれた composerとSchemeのそれは混成して単一のツリーとする事ができます
- さらなる情報のために現在の実装を見てくださいhttp://lists.freedesktop.org/archives/uim-commit/2005-July/000850.html
-
action
- ng-action.scmとして以前のaction.scmから完全に書き直されました(インタフェイスも違います)
- 公開され外部からの制御に利用される、個々のcomposer固有の操作を抽象化します
- actionは、任意のキーシーケンスやchooser UIで選択可能なアイテムにバインドされたり、または単純にaction-eventによってどこからでもアクティベートされます(クライアントアプリケーションも含む)
- それぞれのactionは、そのactionが現在アクティベート可能かを示す事前条件predicateを持っています。それはevmapによって暗黙の状態別キーバインディングに利用されます
- actionオブジェクトには、その固有アクションハンドラのための'self'オブジェクトが保持されています。そのactionオブジェクトをアクティベートする側には、アクティベートされるのが何なのか知る事は求められていません
- 生きたactionオブジェクトではなく名前によるアクティベーションは、受け手のcomposerによって様々に振舞うpolymorphicなアクションハンドリングを可能にします
- さらなる情報のために現在の実装を見てくださいhttp://lists.freedesktop.org/archives/uim-commit/2005-July/000829.html
-
chooser
- 何かを選択する事に関するユーザインタラクションの抽象
- 候補、入力モード、入力メソッド等を選択するのに使われます
- 古典的MVCモデルとしてまとめられた3つの関連オブジェクトから成ります
- Model: choosable (composerから公開されます)
- Controller: chooser (composerの一種)
- View: chooser widget (イベント駆動の抽象UI)
- 候補ウィンドウ、ツールバー、プリエディット中に確保されたテキスト領域等がchooser widgetとして振舞えます
- chooser widgetはユーザの望むように置き換える事ができます
-
evmap
- 任意のイベントシーケンスを他のシーケンスにマップするためのmapper
- 文字列をcomposeしたり、キー操作をactionにバインドしたり、キーイベントを変換したりする事に利用されます。これは伝統的なrkを置き換えます
- 入力されたシーケンスを巻き戻す(undo)事ができます
- 柔軟なキー操作、例えばマルチストローク、キー同時押し(chord)、物理的キー位置情報等を検出できます
- evmap-composerによってcomposerとして振舞う事ができます
-
utext
- 柔軟なテキスト表現の一つ
- 異なるエンコーディングを持つ多言語テキストを包含できます
- 任意のテキストプロパティ、例えばロケール、視覚的装飾、ルビ(日本語の音声註釈)等を加える事ができます
- さらなる情報のために現在の実装を見てくださいhttp://lists.freedesktop.org/archives/uim-commit/2005-July/000830.html
以下の図は、composerフレームワークに基づいたありがちな日本語連文節変換IMを 示します。本当に例として見てください。実際のIMはもっと複雑なツリー構造を持 ちます。
それぞれのノードはcomposerインスタンスを示し、それらは単一の抽象composerイ ンタフェイスで互いに接続されています。
client (ブリッジ)
|
commit, preedit, etc ^|| key, action, chooserイベント等
||v
|
event-dropper (key releaseを正しく捨てる)
|
key-translator (キーのリマップと修飾変換)
|
vi-adapter (viコマンドを監視しactionを発行)
|
event-translator (key -> action mapperとして)
|
mru-chooser (IM switcherの一部として)
|
multiplexer (IM switcherの一部として)
||||
|||+------------------------------+
||+------------------+ |
|+------+ | |
| | | |
| 他のIM 他のIM 他のIM
|
lazy-instantiator
|
event-translator (key -> action mapperとして)
|
chooser (候補セレクタ制御)
|
kana-kanji-converter (もっと複雑なcomposerツリーが内在)
|
migemo-seeker (インクリメンタルmigemoサーチによるカーソル移動)
|
row-editor (composerの列を編集)
||||
+-----------------+||+-----------------------+
| +---++---------+ |
| | | |
skk-composer evmap-composer py-composer evmap-composer
go cha ma z
▼誤 ちゃ 媽 z
A. はい、私はそう信じています。メモリ消費はScheme特有のやり方で最小化され ますし、polymorphicメソッドの呼び出しも特別最適にチューンされます。そして、 KazukiのSigSchemeはさらなる最適化の余地を提供してくれます。
A. はい。私は普通の入力メソッドとは違った特別な機能を多く開発したいのです。 そのような拡張傾向の開発の継続を支えるには、入力メソッドの機能は単機能に分 離され、柔軟に取り外し可能であり、細いインタフェイスによる他の部分との連携 が再構成可能であるべきです。composerインタフェイスがこれに対する私の解です。
さらに、composerのツリー構造が複雑に見えるとは言え、個々のcomposer実装は単 純になる傾向があります。それでも複雑と感じるなら、あなたはIMの全ての機能を 含む一枚岩的なcomposerを書く事もできます。
A. 複数の価値があります。
-
Schemeに触ることなくcomposerを書く事を可能にする
- Cで書かれた既存のIM実装をcomposerに
- C以外の言語のためのバインディング
- Cで書かれたIMマネージャ、IM switcher等。Schemeという言語からの利益を最大化するためのScheme中心主義ポリシーに従い、uimはこれらを提供しません
-
Schemeインタプリタ無しにlibuimを動作させる事を可能にする
- IM switcher等を使わない、Cで書かれた単純なcomposer
- 全てCによるcomposerとして書かれたIMマネージャ、IM switcher、入力メソッド
- uim-agentやuim-serverに接続された、Cで書かれたcomposer proxy
-
実験的開発を容易にする
- 生のcomposerインタフェイスを公開しているIM実装を直接リンク
- foo_composer_new()のようなライブラリ固有のfactoryメソッドによって直接composerインスタンスを生成
- IMリポジトリ、プラグイン、間接インスタンス生成、ロケールに基づいた自動処理、IPC、IM switcher等は一切無し
- このような直接リンクは、中間層に煩わされる事なく実験的開発を行う事を容易にします。例えば、クライアント側の構造に直接アクセスする事は非常に簡単です
A. 現状ではuimにとって採用は難しいです。
入力メソッド開発者やブリッジ開発者のために、どのIMフレームワークで使われる かによらずIMコンポーネントを書けるように何らかのIMフレームワーク間のAPI統 一を望むとは言え、少なくとも当面の間、そのような統一はuimに著しい損失をも たらします。
composerフレームワークは、他のIMフレームワーク内での相当品とは違うユニーク な抽象モデルをいくつか持っているので、何らかのAPI統一は不自然な制限をuimま たは他のIMフレームワークに強制します。そのような統一の代わりに、uim-scimや scim-uimといった単方向のフレームワークブリッジを維持するのが、当面の理にか なった解決策です。少なくともuim 1.0までは。
広範囲の統一に利が無いとは言え、単純な事項、例えばキーシンボルの定義は共有 可能です。時が来たら考慮します。
私のロードマップを以下に記します。他の開発者は別のロードマップを持っている でしょう。もしそれが私のものと衝突するようであればお知らせください。
| 主目的: | composerフレームワークを大まかに確立する |
|---|---|
| 期日: | 数ヶ月後 |
- composerブランチからtrunkにコードをマージする
- composerフレームワークに基づいたng-anthy IMを追加する。もし十分軽くなかった場合、以前のバージョンのanthyは並存する
- canna.cにいくつかの欠けている機能が補完された場合、ng-canna IMを追加する
- ng-anthyとng-cannaはAPIアダプタを通してレガシーIMとして登録される
- libuimとブリッジでdead keysと日本語「ろ」キーをサポートする
- helper protocolとtoolbarにアイコン、セパレータ、及び単一アクションボタンサポートを追加する
| 主目的 | composerフレームワークによる内部整理 |
|---|---|
| 期日: | 年内にリリースされるべき |
-
全ての入力メソッドをcomposerフレームワークに移植する
-
Cで書かれたIM管理コード(uim_im_array関連)をcomposerに基づいたものに置き換える
-
Cで書かれた入力コンテキスト管理コード(context_array関連)はそのまま維持される
-
Cで書かれたIM切り換えコードをcomposerに基づいたものに置き換える
-
キー操作、候補セレクタ等による柔軟なIM切り換えを可能にする
-
chooserとactionを使った、toolbarの柔軟なカスタマイズを可能にする
-
libuimとscm内の多くのレガシーコードを廃止する。ただし、C APIは触れられずに維持される(uim_switch_im()を含む)
-
もし誰かが開発したければ、uim-prefで高度なキーバインディングをサポートする
| 主目的: | uim APIを改訂する |
|---|---|
| 期日: | 来年 |
- 以前のlibuimコードを廃止し廃棄する
- composer APIのCバインディングを追加する
- 単純化と高度な機能の獲得のため、uim API(uim.h)とhelper APIをcomposerに基づいたもので置き換える
- クライアント(ブリッジ)へのcomposerの接続を容易にするため、composer APIに対する何らかのAPI wrapperを用意する
- helperシステムを、プラットフォーム毎の適切なバックエンドを通したインタラクションを扱える何かで置き換える
- 候補セレクタを汎用chooserとして書き換える
- toolbarを汎用chooserとして書き換える
- 上記の変更に合わせて、ブリッジ群を単純化する
- custom機構とAPIを再構築し、uim-prefを改訂する