Etsushi Kato
ekato****@ees*****
2005年 9月 12日 (月) 15:22:43 JST
ヤマケンさん、こんにちは。 On Sun, Sep 11, 2005 at 11:09:14PM +0900, YamaKen <yamak****@bp*****> wrote: > もう一つ確認させてください。私の主張の中では「commit」と > 「プリエディットのクリア」を明確に区別していますが、もしかして加藤さん > の言う「commit」は「reset時のプリエディットのクリア」を指していないでしょ > うか? いえ。 徳永さんも uim ＠ fdo でおっしゃっていましたが、reset に関して議論してい る場合におこる解釈の違いは、reset という概念に、input spot の変化を含 むかそうでないかということだと思います。ぼくや、おそらく、James Su さ んは、gtk+ が gtk_im_context_reset() を input spot の変化に使うことを 前提にした話に基づいているので、ヤマケンとの解釈に違いがでているという ことだと思います。 http://developer.gnome.org/doc/API/2.0/gtk/GtkIMContext.html#gtk-im-context-reset Notify the input method that a change such as a change in cursor position has been made. This will typically cause the input method to clear the preedit state. もちろん、gtk_im_context_reset() が「本当の reset」 について呼ばれるの であれば絶対にコミットすべきでないに同意します。ただ現状はそうでは ないわけで、commit もありうる (Korean input method のように) というこ とでした。 ただし、init 時以外に「本当の reset」というものがどういった状況で呼ば れるのかは、想像できませんでした。 > 以上のように、私はreset時のcommitは許されるべきでないとという立 > 場ですが、「reset時にcommitを許すかどうか」は現在問題になってい > る「reset時のプリディットのクリアについてどの層が責任を負うべき > か」とは別問題なので、同意できなくても保留しておきませんか? はい。 > 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() が発行されるのは 良いと思います。 一例ですが、Mac OS X の挙動をみると、input spot の変化では、IM や bridge ではなく、フレームワークの段階で、preedit が commit され る挙動になっているように見えます。例えば、テキストエディトというエディ タにおいて、文字の入力中に、同じエディタ内の他の文章のある文字をクリッ クすると、compose 中のpreedit の文字はコミットされます。 同じテキストエリア内で input spot を動かした場合の挙動というのは、 http://lists.freedesktop.org/archives/uim/2005-May/001080.html で Paul Hampson さんの話 As a user, I would expect the text in the pre-edit to be comitted at that point, else I would have hit 'esc' (or whatever the cancel key happens to be) before moving off the find the mouse. ie. as far as I am concerned, the preedit area is a projected part of the text, not a piece of text waiting to be inserted. が、しっくりきました。 > ・focus移動イベントはIMに通知されるべき(現時点のuimには欠けてい > る) > ・focus移動時には、IMが必要とするならresetしてよい(この場合プリ > エディットのクリアはIMが行う) > ・focus移動時には、IMが必要とするならcommitしてよい > ・bridgeやtoolkit/application層では、いかなる場合においてもプリ > エディット文字列の自動commitを行うべきではない。それは各IMの責 > 任 はい。いいと思います。現状は、focus_in, focus_out, reset を bridge が application/toolkit から通知されているわけで、reset 以外に、focus_in, focus_out も IM に通知すればいいと思います。それに加え、「本当の reset」 を処理も必要になると思います。もちろん、現在の reset という名前を変 えるのはいいと思います。 ヤマケンさんの以前の話では、bridge 側が commit するという方向でしたの で違和感を感じましたが、今回の IM 側が責任を持つ (commit し得る) とい う話は問題ありません。 -- Etsushi Kato ekato****@ees*****
