2011/2/27 Hiroyuki Ikezoe <[email protected]>:

>> GTK+ 側も、例えば XIM module では、gtk_im_context_reset
>> でプリエディットがあればコミットしてから消去するような動きになっているので、これを期待したアプリケーションでは immodule
>> の種類によってはうまく動かないので直してほしい、ということだと思います。
>>
>> uim の視点では、GTK+ のように安易に gtk_im_context_reset
>> が呼び出されるような状況では、日本語のように長いプリエディットを利用する IM の場合、消去するのは好ましくないという考えのようです。
>
> そうだと思います。
>
> 実際にアプリケーション側の勝手な都合でプリエディットを消去してくれという
> リクエストが来ることはIMにとっては問題ないのでしょうか?
> 例えば、先のByeoruの場合でいうと消去するのではなく、コミットしたいIMだと
> 思うんですが、そういう場合はclear_preeditなるメソッドが呼ばれた時にコ
> ミットしちゃうという実装をするのでしょうか?それはすごく気持ち悪いと思い
> ます。

uim では、ヤマケンさんの議論によりユーザ視点で
 * reset-handler
 * place-handler (カーソルがジャンプして新しい地点に移動した場所で呼ばれる)
 * displace-handler (カーソルがジャンプするので、移動する前の古い地点で呼ばれる)
という物を用意しています。またプラスして focus-in-handler, focus-out-handler
もありますが、こちらは曖昧さはないのでここでの議論では問題ないと思います。

ここでの reset は"本当のリセット" ということで、byeoru.scm でも確定はせず
消去のみの挙動です。skk.scm でも reset で消去、他の handler では確定も消去も
しません (anthy.scm ではここでの議論を反映せず、ずっと放置されていますけど…。
せっかくですから、あとで直しておこうとおもいます)。

ただ、ちょっと記憶が曖昧ですので、このあたりから続く議論を見てもらえると
正しく理解できるかもしれません。
http://lists.freedesktop.org/archives/uim/2006-October/001573.html
-- 
Etsushi Kato

-- 
Google Groups "uim-ja" group
[email protected]
http://groups.google.com/group/uim-ja/about

メールによる返信