Mac

ここのコメントに書きましたが、久しぶりに MacUIM (MacUIM-0.5.2-7) をコンパイルしました。Tiger と Leopard の intel マシンで動いています。uim-xim も入れてあるので、これを動かせば X11 で入力する場合にも一応使えるかもしれません。すべて Universal Binary にしているので Rosetta 経由でも動作しますが、PPC マシンで大丈夫かどうかは不明です。

【11日追記】なぜか uim-prime がバグってたので、libuim-prime.so だけ入れ替えた MacUIM-0.5.2-8 を置き直し、上のリンクも張り直しておきました。(さっき文章を書いている途中、なぜか魔が差し SKK から PRIME に切り替えてしまったのですが、Finder を含むすべてのアプリケーションが無限ループに突入しびびりました…)
【追記終わり】

【18日追記】まだ uim-prime のバグが残ってました。えんが変換できないというのを見て、試してみたところ見事再現。MacUIM-0.5.2-9 として r5191 の uim を入れ直しておきました。
【追記終わり】

【さらに追記】これより新しい MacUIM は、

http://macuim.googlecode.com/ に置いてあります。
【追記終わり】

ところで最近 Leopard を使うようになって気付いたのですが、リスト表示の Finder で、ファイル名の変更時に日本語を入力してリターンキーで確定すると Finder がクラッシュしてしまいます。AquaSKK を使っても同様で (ATOK もそうらしい)、ことえりではクラッシュしないということから、TSM IM と Input Method Kit を利用した IM の違いということなんでしょうか?

Tiger ではリターンキーでファイル名のプリエディットを確定すると、変換文字が確定するだけでファイル名の変更は起こらないのですが、Leopard ではリターンキーのイベントが Input Method の処理だけでなく、そのまま Finder でも処理されてしまっているようで、ファイル名も同時に変更されてしまいます (さらに TSM IM では HIToolBox の中でクラッシュしてします)。おそらく、ファイル名変更中の入力コンテキストが破棄されてしまって、TSM の処理がクラッシュしているんじゃないでしょうか。

これまでの (少ないですが) 経験上、このあたりのイベント処理はいつもだれかがバグを混入させる気がします。ということで少し自分も反省して、ここの所ほったらかしにしてきた Mac OpenOffice.org での NSTextInput Protocol の利用あたりを直してみました。aquavcl05 がマージされるまでは、最近提供されている Aqua OOo は変なのでご注意ください。まあ、OTF/CFF フォントの PDF やプリント出力が依然できないので、どっちにしろ実用するにはまだまだのようです。