How to enable underscore on VMware Server 2

Underscore with jp106 keyboard worked on VMware Server 1.0.x after adding:

xkeymap.keycode.211 = 0x073

But it doesn't on VMware Server 2. $HOME/.vmware/preferences still seems to be alive to do something - just found a symbol in binaries. I don't know what it's for.
After some investigation, it could be enabled again with $HOME/.vmware/config, by adding same thing.

Enjoy,

クリスマスツリー

最近いろいろ忙しくネタを仕込む時間もないので、非技術ネタをひとつ。

一昨日注文してた物が届いて、昨日仕事から帰った後に組み立て、嫁といっしょにセッティング。まだいくつかついていない装飾はあるけど、とりあえず記録。もうそういう季節が迫ってるんだなあ。

XIMプロトコルの闇

XIMプロトコルにはトリガーキーをライブラリ側へあらかじめ通知することできる。最近の実装ではこれらのイベントフローを使わずに常にキーイベントをすべてXIMサーバ側にforwardさせ、然るべきキーを受け取ったらpreedit開始/終了などのようにやっているようだけれど。
このトリガーキーを通知するイベント、XIM_REGISTER_TRIGGERKEYSというイベントなのだけど、次のように解説される:

Using the Dynamic Event Flow model, an IM Server sends
XIM_REGISTER_TRIGGERKEYS message to the IM library before
sending XIM_OPEN_REPLY message. Or the IM library may sup-
pose that the IM Server uses the Static Event Flow model.

まあここまではへえそうなんだ、で済むのだけれど、問題はそのフォーマット:

    XIM_REGISTER_TRIGGERKEYS (IM Server -> IM library)
      2     CARD16                input-method-ID
      2                           unused
      4     n                     byte length of on-keys
      n     LISTofXIMTRIGGERKEY   on-keys list
      4     m                     byte length of off-keys
      m     LISTofXIMTRIGGERKEY   off-keys list

input-method IDってXIM_OPEN_REPLYで初めて通知される。つまり先にこっちを送ると宛先が不明になる。実際このような挙動をする実装のパケットを除いてみるとinput-method IDは0となっている。まあ0以外送りようがないわな。
ちなみに、リファレンス実装に近いkinput2のソースコードには興味深いコメントがある:

/*
* Notify conversion trigger keys.
*
* Note:
* The spec says that XIM_REGISTER_TRIGGERKEYS message should
* be sent to the client bofore XIM_OPEN_REPLY message, in
* order to use dynamic event flow model. However, this
* does not work with current Xlib implementation. So we
* send XIM_REGISTER_TRIGGERKEYS just after XIM_OPEN_REPLY,
* which works fine.
*/

どの実装ならあの仕様は動くんだろう?

[Update: 2008-11-05] しばらく更新してないのでお茶濁しに。XIM_SET_EVENT_MASKの説明にこんな記述がある。

                                       If input-context-ID
is set to zero, the default value of the input-method-ID
will be changed to the event masks specified in the request.

まあXIM_REGISTER_TRIGGERKEYSも同様に、ってことなんだろう。にしても0しか送りようがないんだからだったら初めからいらんだろう、ってのが正直な感想だけど。

libgxim

GObjectベースのXIMプロトコルライブラリです。

http://code.google.com/p/libgxim/

コアな部分はだいたいできていますが、これ使ってサーバないし、アプリケーション側で何かをするにはまだ実装が足りてません。当面の目的はimsettingsのXIM部分の切り替えに使うために書いてます。ただの垂れ流しだと切り替えた瞬間にアプリがフリーズとかあったんで。
Google Groupsにグループを作成したので、宣伝も兼ねてblogに書いてみました。

XIMプロトコルのproxy?部分のコードに興味のある人はこちらからどうぞ。

Re:「コミッタは安易に任命できない」が積極的に名乗り出るのは歓迎

亀田さんのblogところより。

元記事読んでみたけど、ケースバイケースかなあ。まあ誰かに意見主張を押し付けるものでもないけれど、気になったのは、「なんでそんなにコミッタになりたいの?」ってことかな。コミッタにしかできないことなんて、直接コードをVCSにブチ込めるってだけのことで、他は誰にだってできること。他に違いなんてないよね、だってそれがOSSなんだから。
パッチ入れてもらうのにやりとりが面倒?パッチがrejectされた?開発者側になんら欠陥や落ち度がないとは言い切れないけれども、そういうのに煩わしさを感じるからコミッタになりたいって人は遅かれ早かれそのプロジェクトから去らざるを得なくなるんではないのかなあ。パッチが放置?…まあ時々あるよね。ともあれ、「コミッタになりたい理由」ってすごく興味深い。

どのタイミングでコミッタとしての権利を誰かに付与するのかは人それぞれだろうけど、先に与えようが、ちょっとした成果で与えようが、みっちりこき使ってから与えようが、結局はその人をどこで信頼するか、ってことなんじゃないのかねえ。プロジェクトが小さいうちは、「そこそこできる人なら誰でもいい、とりあえず軌道に載せるためには人手が必要」とか、大きくなってきたら、場合によっては技術力を優先するかもしれないし、協調性も兼ね備えてもらいたいと思うかもしれない。みたいな＋αはあるだろうけど。あからさまにできない人をコミッタにするとか、破戒の限りを尽くすような人にはコミッタにしたりしないよね。

まあ、チラ裏だけど。