YamaKen
yamak****@bp*****
2004年 10月 28日 (木) 20:44:50 JST
ヤマケンです。 他の開発者の方(特に足永さん、徳永さん)と作業が被るのを避けるため、 私の今後の予定を晒しておきます。 ・property.scmの作り直し (〜11月初) helper protocol経由で扱われるpropertyのハンドリングを簡略化す るための仕組を作成しました(property.scm)が、徳永さんがproperty の枠組で想定していた仕様と食い違うモデル化がなされていたため、 uim ＠ fdoの議論に基づいて作り直しています。ようやく新しいモデル と設計が固まってきたので今後実装、テスト作成、各IMへの導入に進 みます。 ・custom APIの修正 (11月上旬) uimの各種設定情報を(GUIツールから)カスタマイズするためのAPIと して5月頃にcustom APIを作りましたが、Schemeインタプリタとのイ ンタフェイスに問題があったため現在はbrokenな状態になってます。 property.scmの件が片付き次第以下の方針に基づいて対応する予定で す。足永さんの方で何か意見や作業予定がある場合は早めにお知らせ ください。 http://lists.sourceforge.jp/mailman/archives/anthy-dev/2004-October/001112.html できればuim 0.4.6にはuim-prefを間に合わせたいと思ってます。 ・rkに代わるローマ字かな変換機構の作成 (11月一杯) かな入力への根本的対応や「いんてrねt → internet」のようなアル ファベット変換の問題も同時に解決する事を考えています。可能であ ればNICOLA等に必要な同時押し検出も。足永さんはこの件の対応を中 止してGUIに集中しているものと認識していたので私がやるつもりで した。 現在anthy.scmには足永さんが途中まで作業されたraw-strのコードが 入ってますが、この延長線上の方式では将来の拡張やメンテナンスが うまくいかないと考えているので、rkの代替と歩調を合わせて汎用的 な仕組を作ってrk機構を各IMから分離したいと考えていました。また、 コードそのものも現在のrk.scmやjapanese.scmのように手書きの再帰 を多用するのではなく、最近私が書いたSRFI-1 proceduresや ustr.scmを活用して単純な仕組を作ろうと考えていました。 現在足永さんの手元ではどのような状態なんでしょうか? また、rkの 代替は視野に入っていますか? それから、徳永さんは現在リポジトリにあるhk.scm以外に何か作業さ れてますか? ・キー入力とコマンドの分離 (12月以降) 各IMが直接キー入力を見るのをやめ、汎用の入力ハンドリングフレー ムワークに分離します。これにより現在各IMで行われているキー入力 の不正な取り扱い(bug #528)やQWERTYキーボードの仮定を根本的に解 決するとともに、同時押しやマルチストロークといった複雑なキー入 力を任意の操作に割り当て可能にします。実現のためにはrkの代替が 必要です。 ここが私にとって一つのマイルストーンになります。今まで地道に進 めてきた内部改良やテスト整備はここに至るために必要な作業です。 ・ustore frameworkの導入 (来年) 情報の格納/取得/伝播/通知を統合するustoreという仕組を考えてい て、uim_get_*()系の情報取得関数とcallbackによる更新通知、 custom API, helper protocol, helper library, property 等をそれ で置き換えて単純化したいと考えています。 これより優先度が高いと見なしている作業(各IM共通機能の分離と内 部実装の隠蔽)があるので提案はまだ先になりますが、領域のかぶる 部分で何か変更を考えている人がいるなら先に議論した方がいいと思 うので言ってください。 他にも細かい作業は色々ありますしimmodule for Qtの作業も随時発生 しますが、大きな予定としてはこれぐらいです。 ------------------------------- ヤマケン yamak****@bp*****
