YamaKen
yamak****@bp*****
2005年 10月 21日 (金) 14:36:29 JST
ヤマケンです。uim APIの改訂もじりじり進めといた方がいいですね。 At Thu, 20 Oct 2005 16:39:51 +0900, ekato****@ees***** wrote: > On Fri, Sep 16, 2005 at 08:57:28PM +0900, > YamaKen <yamak****@bp*****> wrote: > > > uim-fooのresetハンドラにその責任を移譲するという事はプリエディッ > > トのクリアを行なう/行わないという選択権をuim-fooに与えるという事 > > ですが、それが正しい設計だとは思えません。 > > > > もちろん「本物のreset」ではないカーソル移動通知としてのresetに対 > > しては適切な対処が必要でしょう。しかしそういったクライアント毎の > > 事情はbridgeで隠蔽し、libuim以下はあくまで本物のresetやカーソル > > 移動通知のみを扱うべきだと思います。 > > カーソル移動通知に関しては、クライアントではなく IM ごとに事情が異なる > 可能性があるので、ここは IM に任せてもいいのではないでしょうか? 日本語表現が曖昧で誤解させてしまったようですが、多分加藤さんと同 じ考えだと思います。私が言いたかったのは以下のような事です。 ・本物のresetとカーソル/focus移動通知はそれぞれ別個のAPIとして必 要 ・IM側はそれらAPIの挙動はbridgeによって変わらないものとして扱う ・ツールキットレベルでの偽reset等から各uim APIへの変換は各bridge の層で隠蔽する 具体的には以下の5つのAPIがIMに提供される必要があると思っています。 詳細はuim ＠ fdoで議論しましょう。なぜこんなに細分化する必要がある のかはuse case毎に解説が必要なんで、私から話を振るなら文書作成の ためちょっと先になります。先に詰めときたい話題があれば加藤さんの 方から投稿してください。また、もし余裕があれば問題点/動機/これま での経緯等を軽く整理してもらえるとこちらの準備も早められると思い ます。 - reset(本物) - focus-out - focus-in - leave-spot - locate-spot - locate-spot-with-focus > > > > ・toolkit/applicationはfocus移動時にresetを発行すべきでない > > > > > > この focus 移動というのがまた問題です。uim ＠ fdo の議論でもありましたが、 > > > focus in, focus out, input spot change の三種類あると思います。ぼくも > > > focus_in, focus_out では reset は発行すべきでは無いと思いますが、input > > > spot の変化では、現状のように gtk_im_context_reset() が発行されるのは > > > 良いと思います。 > > > > 実はinput spot changeの問題は失念してしまってたんですが、確かに > > focus移動とは区別する必要がありますね。 > > > > 前述のようにuim内ではresetという名のもとにinput spot changeに相 > > 当するハンドリングを行うのには反対なので、今入れたいという話なら > > uim ＠ fdoに議論を移しましょう。私の方でも考えてみましたが、もっと > > 細分化する必要があるように思います。 > > 了解しました。現状の uim の reset は本物の reset に対するものとして、 > その他にカーソル移動のコードがあってもいいと思います。 はい。カーソル/focus移動通知APIは必須です。 immodule for Qtのドキュメントでも解説しましたが、preedit relocation等を考えると上記のように5つのAPIが必要と考えています。 > で、まだ議論が必要かもしれませんが、もし追加するとなるとどのタイミング > (version) になるでしょうか。徳永さん、ヤマケンさん? 私は0.5シリーズの中でやってしまってよいと思います。混乱を避ける ためr5rsがtrunkにマージされた後が望ましいですが、もしマージ前に 議論があっさり終わって実装待ちになってしまったら再考しましょう。 ------------------------------- ヤマケン yamak****@bp*****
