IIIMF や iiimf-skk をホゲりたい[11] 人のためのヒント集です。
iiimf-skk 全体の動作を知りたい → 8.2.「iiimf-skk を hack する」
iiimf-skk の挙動を自分用に変えたい → 8.3.「iiimf-skk の httx からの呼び出し」、 2.6.「コンパイル時に必要な設定」 コンパイル時の設定や、 4.「基本的な設定」 使用時の設定 でカスタマイズできる場合もあるかもしれません。
httx が落ちてしまうのを何とかしたい → 8.4.「htt の異常終了」
なかなか iiimf-skk のステータスウインドウが見えないのを何とかしたい → 8.5.「httx の起動が遅い」
iiimf-skk を hack したい方は、 まず famao さんの書いた文書を見るといいかもしれません。 これらの文書は、2002 年 4 月 9 日現在、「まだ全然書きかけ」で、 URL も変更になる可能性があることをご承知おきください。
HACKING-WITH-IIIMF-SKK vol.1 IIIMF-SKK に新たな機能を追加する。
HACKING-WITH-IIIMF-SKK vol.2 IIIMF-SKK の動作の流れ
HACKING-WITH-IIIMF-SKK vol.3 htt_server を デバグする。
iiimf-skk-0.1.18 の頃の情報です。 ご承知おきください。
src/skk.c
が iiimf-skk のライブラリになります。
そこの process_keyevent_hoge
とか
translate_keyevent_fuga
とかが
ほとんどのキーの処理をしてます。
のでカスタマイズするときにはそこからやるのが吉かと。
実際の処理は lib/skkbuffer.c
でします。
skk_buffer_fuga
という関数は
lib/skkbuffer.c
にあります。
skk_process_keyevent_hoge
を呼ぶのは、
if_skk_SendEvent
。
Xのイベントを iiim server が処理して
skk.so
のskk_SendEvent
をたたきます。
初期化するときに iiimf に
skk で使う関数を登録している。
iiimf-xiiimp-1.2-0.020020207004k での情報です。 strace $IM_EXEC している時に httx が落ちた(7.7.「htt を再起動する」)ので、 その時の様子を載せておきます。
[org.kondara.skk.PaletteAux] notified DRAW via ClientMessage [org.kondara.skk.PaletteAux] received DRAW via property Message: fuga 1 sv[00]=かな ) = ? ERESTARTNOHAND (To be restarted) --- SIGCHLD (Child exited) --- wait4(-1, [WIFSIGNALED(s) && WTERMSIG(s) == SIGPIPE], WNOHANG, NULL) = 29759 write(2, "htt : Error - htt_server died. D"..., 57htt : Error - htt_server died. Don't know how to recover ) = 57 _exit(1) = ?
ふと思ったんだけど、なんで、httx って SIGPIPE をニギらないんだろ。 httx なり htt_xbe なりが SIGPIPE をニギってしまえばこ の部分は解決すると思うんだけどなぁ。
iiimf-xiiimp-1.2-0.020020207004k での情報です。 strace $IM_EXEC すると、
$ strace $IM_EXEC
:
fork() = 29759
:
ioctl(3, 0x541b, [0]) = 0
read(3, 0xbfffe9e0, 32) = -1 EAGAIN (Resource
temporarily unavailable)
select(4, [3], NULL, NULL, NULL
というステップまできて、
select()
で時間がかかっていることがわかりました。
$IM_EXEC は、
ロケールを設定して、
/usr/lib/im/httx を
適当なオプションを付けて実行します(3.「sdr コマンドを使えない場合の使用方法」)。
この時点でトレースバックすると、
(gdb) bt #0 0x402544ae in __select () from /lib/libc.so.6 #1 0x401167e4 in _XlcPublicMethods () from /usr/X11R6/lib/libX11.so.6
ということで、
XlcPublicMethods ()
という関数がアヤシイといいうとは
わかるのですが…。
ネットワークにつながっていない状態で、
/etc/resolv.conf
にnameserverが1つ書いてある場合には、
変換が遅く、
2つ書いてある場合は変換ができなくなる症状があるようです。
getaddrinfo(3)がネームサーバーに問い合わせを送って、
タイムアウトになるのを待っているようです。
とりあえずは、
ネットワークにつながっていない場合には、
Xを起動する前に/etc/resolv.conf
のnameserverの行を
コメントアウトするという対処方法もあります。