一回 Linux パーティション全部消したりしたので、10.2 を入れ直したわけですが、scim-bridge については m17n で提供されるようになったので、自分でビルドした奴じゃなく、そっちのを使おうと思って入れました。
が、なぜか GTK 64bit アプリでしか使えない。
scim が使えない firefox や、scim-qtimm を入れれば scim 使えるけど入れるとコンカラが死にまくるので入れたくない QT アプリで scim-bridge が使えない。
要するに、必要ないところで使えて、必要なところで使えないというマヌケな状態。
「んだよもー」と思いながらも、先週までは完全廃人状態だったので調べることもせずにほったらかして、QT アプリや firefox とかでは kinput2/canna 使ってました。
しかし、「やっぱ俺 ぱそこん 嫌いだわ。Windows もクソ、Linux もクソ」「他のことも一切何もやる気がせん。飯？メンドクサイ。風呂？メンドクサイ」とかいう「ひたすら真っ直ぐ後ろ向き」なドツボ状態からもようやく抜け出したので、ボチボチと調べてみた。
まず、QT アプリは、「入力方法の選択」の一覧の中に scim-bridge が出てこない状況だった。見ると、im-scim-bridge.so が /usr/lib/qt3/plugins/inputmethods にあったので、「これかな？」と思って /usr/lib64/qt3/plugins/inputmethods に移してみたが変わらず。
結局、m17n から qt3-3.3.8-73.1.x86_64.rpm 落としてきて qt3 のバージョン上げたら、/usr/lib/qt3/plugins/inputmethods にあるままでも行けました。
ただ、scim-bridge-qt-0.4.12-2.3.x86_64.rpm でインスコされる im-scim-bridge.so のパスが /usr/lib/qt3/plugins/inputmethods なのはどうなんでしょ。
/usr/lib64/qt3/plugins/inputmethods でないとマズいと思うんですが。
今は build service が x86_64 環境用 32bit パッケージの作成に対応してないらしくて、scim-bridge-qt-32bit のパッケージがないからいいかもしれませんが、scim-bridge-qt-32bit ができたら上書きしちゃうんじゃないのかなぁ。
で、これ、何が悪いかと言うと、多分 scim-bridge がパスを決め打ちしちゃってるか何かで、64bit 環境でビルドしても im-scim-bridge.so が /usr/lib64/qt3... じゃなく /usr/lib/qt3... に作成されちゃうのが問題なんじゃないかという気がする、とか調べもせずに言ってみるテスト。自分でビルドしたときもそうなって、spec の install のところで /usr/lib64/... に mv した覚えがあるから。違ったらごめんなさい。
他のディストリのパッケージャの人はどうしてんだろ？
GTK 32bit の方は、scim-bridge-gtk-0.4.12-2.3.i586.rpm をそのまま入れて、
# gtk-query-immodules-2.0 > /etc/opt/gnome/gtk-2.0/gtk.immodules
で行けるはずだと思うんだけど、で、実際
$ GTK_IM_MODULE=scim-bridge /home/ore/bin/firefox/firefox &
とすれば使えるんだけど、単に
$ /home/ore/bin/firefox/firefox &
だけだったり、メニューから起動したりするとなぜか canna になっちまう。
ミケさんが言うには「scim-bridge は /etc/X11/xim.d/ 以下の設定でプライオリティを一番高くしてるから先に使われるはずだ」ということなんですが、firefox や thunderbird ではそうならない。
確かに例えば、scribes の i586 なパッケージを入れて起動すると、ちゃんと scim-bridge になって、mike さんの言う通りになるんですが。
自分で build してたときは /etc/X11/xim.d/ 以下に scim-bridge のエントリは何も入れなかったが、それでも firefox や thunderbird で scim-bridge が先に使われてたんだよなぁ。
この状況からすると、firefox や thunderbird は GTK 32bit のアプリだけどさらにまた特殊で、違った動きをする、ということのように思えるんだけど。よう分からぬ。どこ見て順番決めてるんだろ？
とりあえず、KDE のメニューエディタ開いて、firefox の「コマンド」欄のところを
GTK_IM_MODULE=scim-bridge /home/ore/bin/firefox/firefox
にして凌いでるんですが(thunderbird も)、何か情けない…。
(ちなみに、自分の ~/.xim は
export XMODIFIERS="@im=kinput2"
export GTK_IM_MODULE=scim
export QT_IM_SWITCHER=imsw-multi
export QT_IM_MODULE=scim-bridge
scim -d
kinput2 -xim -kinput -canna -cannaserver unix &
と、辞書いじってる関係で canna も一応使える状態にしておく必要があるので、変態構成になってます。)
【関連する記事】
とりあえず、pkg-configでqt-mtのprefixを取得してそこから割出していますが、
たぶんSuSEでは話が違うのだと思います。
参考:
http://lists.sourceforge.jp/mailman/archives/scim-imengine-dev/2006-August/001297.html
気になって調べてみると、$QT_DIRから割出すのが推奨されているようですが、
しかしQt3、Qt4が併用されている環境ではどうなるのか...
0.2.13ではQt4も対応予定なので、それまでに調べておきます。
やっぱ、ちゃんと見てから書くべきでした m(__)m
こちらでも SUSE でどうなってるか後で見てみます。
でいいんでしょうか。
M17Nのscim-bridgeの初期リリースでも同じ記述がされてたんですが、GTKアプリでまともに使えなくって....。
今はM17Nのscim-bridgeでも
export GTK_IM_MODULE=scim-bridge
に変更されてますが...。
export GTK_IM_MODULE=scim-bridge
ですよ。
(ximやscimを指定したら当然そちらが代わりに動くだけです)
ですよ。
誤解を招いてしまった様で...。
その設定ではscim-bridgeは動かない(
M17Nのscim-bridgeパッケージの初期リリースと同じ間違いをしている)のでは?というつもりでした。
>
> でいいんでしょうか。
不味いですね。
これでは、SCIMが優先して動きます。
SuSEのQtはx86_64でも/usr/lib/qt3に入れられていますね。
/usr/lib64/qt3は/usr/lib/qt3へのリンクです。
すると、pluginsのディレクトリがかち合ってしまう訳ですが、そのあたりはプラグインのサフィックスにx86_64を付け加えてどうにかしているようです。
そして、例のSCIM-Bridgeのパッケージはどうもそうしたプリフィックスをつけ忘れているようですね。
QTDIRはqt3とqt4でかち合うので通常qt3の方しか設定していないようです。
一方、pkg-configは修正すればどうやらOKそうです。
近い内に、qt4をサポートした0.4.13を出します。
別の記事を書きましたので、そちらをご覧頂けると幸いです。
> 大力さん
suse のことまで調べていただきありがとうございます。
しかも自分よりよく分かってらっしゃるという…(^^;