YamaKen
yamak****@bp*****
2005年 7月 13日 (水) 03:11:58 JST
ヤマケンです。 uim ＠ fdoにcomposer frameworkの解説を投稿したんですが、重要な内容 なのでこちらにも和訳を流しておきます。 私がこれからuimでやろうとしている事とは指向が合わない人も結構い ると思いますが、この解説で少なくとも誤解から議論が噛み合わないと いう事は減らせるんじゃないかと期待してます。 まだまだ先は長いんですが、気長にお付き合いいただけると嬉しいです。 ---------------- 皆さんこんにちは。composerフレームワークのcomposer API(Scheme版)を公開レ ビュー向けに定義しました。 これに関するあなたの要求と意見をお知らせください。 このメッセージは開発者への説明として書かれています。エンドユーザ向けの利点 と機能は十分に記述されていません。またの機会を待ってください。 What's going on: the composer framework 1. composerフレームワークとは何ですか? 2. 現状のuimのアーキテクチャ的問題点 3. composerフレームワークの主要コンポーネント 4. composerに基づいたIMの例 5. FAQ 6. ロードマップ 1. composerフレームワークとは何ですか? composerフレームワークとは私によって完全に再構築された次世代uimの中核アー キテクチャです。 それは数々のアーキテクチャ的問題点を解決し、入力メソッドの開発を簡単にし、 入力メソッド全体をいじるのではなく再利用可能なコンポーネントの開発による機 能強化を可能にし、プラットフォーム固有の使いやすいIM環境を構築するために適 切に分離されたコンポーネントを提供し、柔軟なIMカスタマイズを可能にします。 このフレームワークそれ自身はユーザレベルIM環境や操作体系についてきまったポ リシーを仮定しません。それらは上のレイヤの問題であって、このフレームワーク がすべき事は適切に責任の分離された再利用可能なコンポーネントを提供する事に よって、どんなシステム構成をも可能にする事です。「GUIツールキット」と「デ スクトップ環境」になぞらえて、このフレームワークを「IMツールキット」と呼び、 「上のレイヤ」を「IM環境」と呼ぶと、このフレームワークの責任範囲について理 解する助けになるかもしれません。 もちろん、「上のレイヤ」はuimの重要な一部分です。私はこのレイヤ分割がプラッ トフォーム固有のIM環境を開発するのを簡単にすると信じています。 このフレームワークは別ブランチ(composerブランチ)にて開発中です。 2. 現状のuimのアーキテクチャ的問題点 - UNIXデスクトップ中心主義の一枚岩的機構群 * モジュール(プラグイン)管理 * 固定流儀の入力コンテキスト生成 * 固定流儀の入力コンテキスト管理 * 固定流儀のIM切り換え方式 * ロケールを認識するIM選出 - 複雑すぎる入力コンテキスト管理方式 * 入力コンテキスト生成処理と、そのインスタンス表現それ自身はCとSchemeに 分散した数々の機構に関わっています。それゆえに私たちは入力コンテキスト をSchemeから簡単に生成して使う事ができません - 不十分な責任の分離と再利用性 * あるコードは、他のコード修正の際の意図しない責任侵害によって容易に壊れ ます * コピー&ペーストされたあふれるコード群が進歩を阻害しています * コピー&ペーストされたコードの膨張は、それが黒魔術の物体になってしまう 前に阻止して健康を回復するべきです これらの問題への解はコードで語られます。 3. composerフレームワークの主要コンポーネント - 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 4. composerに基づいたIMの例 以下の図は、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 5. FAQ Q. このフレームワークは重いように見えます。使いものになりますか? A. はい、私はそう信じています。メモリ消費はScheme特有のやり方で最小化され ますし、polymorphicメソッドの呼び出しも特別最適にチューンされます。そして、 KazukiのSigSchemeはさらなる最適化の余地を提供してくれます。 Q. こんな複雑な構造が本当に必要なんですか? A. はい。私は普通の入力メソッドとは違った特別な機能を多く開発したいのです。 そのような拡張傾向の開発の継続を支えるには、入力メソッドの機能は単機能に分 離され、柔軟に取り外し可能であり、細いインタフェイスによる他の部分との連携 が再構成可能であるべきです。composerインタフェイスがこれに対する私の解です。 さらに、composerのツリー構造が複雑に見えるとは言え、個々のcomposer実装は単 純になる傾向があります。それでも複雑と感じるなら、あなたはIMの全ての機能を 含む一枚岩的なcomposerを書く事もできます。 Q. composer APIのCバインディングによって何が達成されますか? 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等は一切無し * このような直接リンクは、中間層に煩わされる事なく実験的開発を行う事を容 易にします。例えば、クライアント側の構造に直接アクセスする事は非常に簡 単です Q. 何らかの統一IM APIについてどう考えますか? A. 現状ではuimにとって採用は難しいです。 入力メソッド開発者やブリッジ開発者のために、どのIMフレームワークで使われる かによらずIMコンポーネントを書けるように何らかのIMフレームワーク間のAPI統 一を望むとは言え、少なくとも当面の間、そのような統一はuimに著しい損失をも たらします。 composerフレームワークは、他のIMフレームワーク内での相当品とは違うユニーク な抽象モデルをいくつか持っているので、何らかのAPI統一は不自然な制限をuimま たは他のIMフレームワークに強制します。そのような統一の代わりに、uim-scimや scim-uimといった単方向のフレームワークブリッジを維持するのが、当面の理にか なった解決策です。少なくともuim 1.0までは。 広範囲の統一に利が無いとは言え、単純な事項、例えばキーシンボルの定義は共有 可能です。時が来たら考慮します。 6. ロードマップ 私のロードマップを以下に記します。他の開発者は別のロードマップを持っている でしょう。もしそれが私のものと衝突するようであればお知らせください。 - 0.5 (開発版) and 0.6 (安定版) 主目的: 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にアイコン、セパレータ、及び単一アクションボタ ンサポートを追加する - 0.7 (開発版) and 0.8 (安定版) 主目的: 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で高度なキーバインディングをサポートする - 0.9 (開発版) and 1.0 (安定版) 主目的: 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を改訂する ------------------------------- ヤマケン yamak****@bp*****
