YamaKen
yamak****@bp*****
2004年 3月 21日 (日) 06:55:03 JST
ヤマケンです。反応が遅くなりました。 At Sat, 20 Mar 2004 10:47:46 +0900, ekato****@ees***** wrote: > On Sat, Mar 20, 2004 at 02:34:19AM +0900, > TOKUNAGA Hiroyuki <tkng****@xem*****> wrote: > > > On Fri, 19 Mar 2004 00:40:40 +0900 > > Etsushi Kato <ekato****@ees*****> wrote: > > > > > 前者は、skk.scm の skk-prop-handler の修正と、半角カナもラベルに表示す > > > るようにしたものです。また skk-commit-newline-explicitly はデフォルト > > > で true のほうが良い思うので変えてあります。 > > > > これに関しては私はどうなっているのかわかってないので、とりあえず#fのま > > まにしておきました。ヤマケンさんの意見が知りたいです。 ちょっとややこしい状況なので、skk-commit-newline-explicitly?が導 入された経緯から説明します。 まず2004/1月前半の時点では、uim-skkは以下のような挙動をしていま した("I"はカーソルです)。 ▼とうきょうとちよだく【東京都▼千代田区】 ↓ RET ▼とうきょうとちよだく【東京都千代田区I】 ↓ RET 東京都千代田区I ▼牛丼 ↓ RET 牛丼I これはSKKの標準的な挙動と異なり不便なので、[Anthy-dev 414]のパッ チを投稿し、以下のように変更しました。-r353で取り込まれています。 ▼とうきょうとちよだく【東京都▼千代田区】 ↓ RET 東京都千代田区I ▼牛丼 ↓ RET 牛丼 I 後者の「牛丼」の例では確定と同時に改行が入力されていますが、これ は uim_press_key() で真の値を返す事により、ブリッジ側で保持され ているオリジナルのキーイベントを後続の処理に回す事によって実現し ていました。これにより "Key_Return" のようなkeysymに反応して特別 な処理(「Enterを押すと検索開始」等)を行うウィジェットでも期待通 りの動作をするようにしていました。 その後、私の記憶が正しければ徳永さんによって上述のオリジナルのキー イベント差し戻しによる改行入力の代わりに"\n"をcommitするコードが 入りました。これはC-mのような非標準のキーバインドでも改行が入力 できるようになる反面、キーイベントではないので上述のようなkeysym に反応するウィジェットでは特別な処理が行われなくなってしまいます。 これでは困るので、skk-commit-newline-explicitly?を導入して旧来の 処理と選択可能にしました。また、この時点では"\n"をcommitする方の コードでは、以下のような操作を行うとSEGVしていたのでデフォルトは #fとしておきました。 ▼とうきょうとちよだく【東京都▼千代田区】 ↓ RET SEGV 現在のコードではskk-commit-newline-explicitly?が#tの状態でSEGVこ そしなくなったようですが、以下のような問題のある挙動をします (gtk-im-uimで確認)。 ▼とうきょうとちよだく【東京都▼千代田区】 ↓ RET ▼とうきょうとちよだく【東京都千代田区 I】 #fの場合は以下のように正常に動作します。 ▼とうきょうとちよだく【東京都▼千代田区】 ↓ RET 東京都千代田区I このような状況なので、少なくとも今はまだ#fにしておくべきだと思い ます。また、ウィジェット毎の特別な挙動の事を考えると将来もデフォ ルトは#fであるべきだと思いますし、この設定項目自体無い方が良いと 思います。C-mで改行を入力するようなカスタマイズはIM非アクティブ 時にも有効になるようにツールキット側で行わないと意味が無いと思う ので。 ただ、後述のようにcommitとキーイベントの処理順を保証できないよう な環境があるなら残しておく必要はあると思います。 > ▽にほんご > > の状態で Enter キーを押した場合、im-uim なら #t でも #f でも期待どおり > の挙動 （「にほんご」とその場で確定されて、カーソルは次の行に移る）を > するのですが、uim-xim の場合、例えば rxvt 上で vim を使っている場合、 > #f であると、確定された「にほんご」が次の行に来て、カーソルがその後ろ > に位置してしまいます。また、#f の場合、確定したつもりの文字が消えてし > まうこともあったのですが、ちょっと今は再現できません。#t なら期待どお > りの挙動です。 これはuim-ximの問題ですね。commitとキーイベントの処理の順序が入 れ換わってしまっているんだと思うんですが、uimから制御が戻ってき た後にイベントキューが挟まっているようなので、この2つの操作の順 序を保証できるのか私にはちょっとわかりませんでした。Xの知識が無 いもので。 ------------------------------- ヤマケン yamak****@bp*****
