Etsushi Kato
ekato****@ees*****
2005年 1月 2日 (日) 12:50:15 JST
ちょっと前の話題ですみません。compose key についてです。 On Wed, Nov 10, 2004 at 08:00:55PM +0900, TOKUNAGA Hiroyuki <tkng****@xem*****> wrote: > ウムラウトやアクサンなどを入力する方法としてはDead keyやMulti keyがあ > ります。これらをまとめてComposeKeyと呼びます。GTK+のgtk_compose_seqsとい > うテーブルにはdead keyとmulti keyの両方が定義してあるので、たぶんこれが > 正しい呼び方だと思います。 > > GTK+ではCompose Keyに関してどういう扱いをしているかというと、 > GtkIMContextSimpleという専用のcontextを用意しています。 > GtkIMContextSimpleはContextという名前ではありますが、実際にはGTK+組込み > のimmoduleの一種と捉えた方がわかりやすいと思います。GtkIMContextSimpleは > 800個以上の要素を持ったCompose用のテーブルを持っており、これを使って > ComposeKeyに対応しています。試してはいませんが、たぶんX側のcompose > sequenceのファイルは利用していません。 そうですね。Perl script によって変換した物を table にして使っていると gtkimcontextsimple.c にコメントしてありますね。 > uimでは、GTK+用のBridgeは内部にGtkIMContextSimpleをもっており、これを > slave contextと呼んでいます。uim側で処理しなかったkey eventはこのslave > contextに処理させています。例えば、uim-anthyで半角英数モードになっている > 場合、Multi_key a eと入力すると、これら3つのkey eventが全部uim側ではスル > ーされてslave contextに回されるので、結果としてaeがくっついた奴が入力さ > れます。 > このmaster/slave contextの方法でGTK+の範囲では快適な生活が送れるはずで > すが、GtkIMContextSimpleに頼っているので、他の環境、例えばuim-ximだとか > UimQtだとかでは悲しい状態になります。（悲しいというか、これまでの事を考 > えると変わらない訳ですが。） 確かに海外の方から、XMODIFIERS=@im=uim を設定している場合 XIM client で compose が使えない、と幾つかメールが来てました。 > では単純に、GtkIMContextSimpleのデッドコピーをlibuim側に取り込んで > GTK+用のBridgeからslave contextを削除すればそれで問題は解決するのかと言 > うと、他にkey eventの扱いの問題があります。 > libuim側ではkey eventは32から126までの間のキーコードを表すkeyと、 > shiftやctrlなどの修飾キーが押されているかを表すstateの組合せで表現されま > す。32〜126というところでわかると思いますが、これでは表現できないキーイ > ベントがあります。この問題を解決しない間は、libuim側では満足な > ComposeKeyサポートを提供できないので、GTK+用Bridgeからslave contextを削 > 除できません。 そういった理由があるので、昨日 uim-xim 側で X の compose を扱うように コードを追加しておきました。機能的には、XMODIFIERS を設定しない状態と まったく同じものが使えるようにしておきました。client の locale に応じ て、/usr/X11R6/lib/X11/locale/*/Compose の機能をすべて使えます。 libuim 側で deadkey と Multi_key が扱えるようになった時には、この機能 は disable しておきます。 -- Etsushi Kato ekato****@ees*****
