Etsushi Kato
ekato****@ees*****
2005年 10月 20日 (木) 16:39:51 JST
ヤマケンさん、こんにちは。 詳しく書いて頂いたのに、返事が遅くなってしまいすみません。 「本物のリセット」について、同じように認識できたと思います。 On Fri, Sep 16, 2005 at 08:57:28PM +0900, YamaKen <yamak****@bp*****> wrote: > 現状のGTK+が"reset"という名前でカーソル移動を通知しているとして > もuimがそれに従う必要はないので、私としてはuim側では本物のreset > とカーソル移動通知は分離すべきと考えます。 はい、そう思います。 > 以下、せっかくなので本物のresetについての意見です。「本物の」 > resetについてなら加藤さんも同様に考えていると認識してますが、一 > 応確認お願いします。 > > > 各IMのresetハンドラでプリエディットのクリアを行う事にすると本物 > のreset発行時には以下のようなresetの行き/帰りが発生しwidgetの > preeditが二重にクリアされる事になりますが、w->reset()に対する > w.peのクリアがuim-fooからのプリエディット更新指示によってなされ > るのは責任の所在の観点からおかしいと思います。 > > w->reset()発行の時点でプリエディットのクリアが目的である事は自明 > なのだから、行きの経路上でそれぞれの要素が責任を持って各自の保持 > するプリエディットのクリアを行うべきで、GTK+のようにwidget自体が > プリエディットのクリアを行わない場合にはbridgeがそれを吸収すべき > というのが私の主張です。 了解です。本物の reset では、bridge 側でクリアしましょう。 > uim-fooのresetハンドラにその責任を移譲するという事はプリエディッ > トのクリアを行なう/行わないという選択権をuim-fooに与えるという事 > ですが、それが正しい設計だとは思えません。 > > もちろん「本物のreset」ではないカーソル移動通知としてのresetに対 > しては適切な対処が必要でしょう。しかしそういったクライアント毎の > 事情はbridgeで隠蔽し、libuim以下はあくまで本物のresetやカーソル > 移動通知のみを扱うべきだと思います。 カーソル移動通知に関しては、クライアントではなく IM ごとに事情が異なる 可能性があるので、ここは IM に任せてもいいのではないでしょうか? > > > commit/focusまわりについては私は以下のような見解を持っていますが、 > > > この件については必要になった時点でuim ＠ fdoで別途議論する方がよい > > > でしょう。 > > > > > > ・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 に対するものとして、 その他にカーソル移動のコードがあってもいいと思います。 で、まだ議論が必要かもしれませんが、もし追加するとなるとどのタイミング (version) になるでしょうか。徳永さん、ヤマケンさん? -- Etsushi Kato ekato****@ees*****
