2011/2/27 Hiroyuki Ikezoe <hiike...@gnome.org>: > 実際のところ、アプリケーション側からそういう風に強制的にコミットする機 > 能って必要なんでしょうか？ ”本当のリセット”のことも考えると以下の３つの > APIが要るんじゃないかと考えてる人がいる気がします。 > > a) gtk_im_context_reset: プリエディット中に呼び出された場合の動作は各IM > の実装に任せる > > b) gtk_im_context_clear_preedit: プリエディット中の状態を初期化(プリエ > ディット文字列を削除) > > c) gtk_im_context_fix_preedit: プリエディット中の文字列をそのままコミッ > ト > > この中で、今のGTK+にはa)しかないわけですが、個人的にはアプリケーションが > b)c)を呼び出す必要性がいまいちピンと来ないので（IMのプリエディット中にそ > の状態をどうするかはアプリケーションには決められないと思ってるので）、現 > 状のままでもgtk_im_context_reset時の挙動に関して開発者の間で合意が取れて > いれば（GTK+のドキュメントに修正を入れた方がいいかもしれませんが）、今の > ままでよいのではないかとも考えています。 > > ただ、2)の場合にもresetが飛んできてしまうので、その点ではGTK+を修正しな > くてはいけませんが。
前のスレッドのなかのさんの話が、まさしくアプリケーション側 (Firefox) が強制的にプリエディットを消去したい、という話だと思います (いくつかの text field がひとつの im context を共有しているため)。 GTK+ 側も、例えば XIM module では、gtk_im_context_reset でプリエディットがあればコミットしてから消去するような動きになっているので、これを期待したアプリケーションでは immodule の種類によってはうまく動かないので直してほしい、ということだと思います。 uim の視点では、GTK+ のように安易に gtk_im_context_reset が呼び出されるような状況では、日本語のように長いプリエディットを利用する IM の場合、消去するのは好ましくないという考えのようです。 よって、最低、a) と b) の組み合わせがあれば良いのかもしれません (a と c の組み合わせでもよいかもしれませんが)。 MacOS X の Cocoa では、commitComposition という API (c 相当?) しか存在しないようですが、それほど大きな問題は起きていないように感じています。 -- Etsushi Kato -- Google Groups "uim-ja" group uim-ja@googlegroups.com http://groups.google.com/group/uim-ja/about
