Wnn7 & SMTPサーバとしてだけ使ってた古いマシンがapt-get upgrade(VIneSeed)の際に失敗。rpmデータベースが破壊されたという事態に。おそらく、HDDの故障だろうなと。
いろいろ復活も試してみたけど、うまくいかないしHDDが本当に故障なら再インストールが一番。ついでにIMAPもこちらに移してみることにした。
11月 152004
11月 102004
10月 202004
先日のエントリーにつけていただいたコメントやTAM氏の日記を見てて、なんとなく私の中のもやもやがはっきりしたなっていうのがひとつ。
「kinput2よりましで、商用クラスの精度のあるUIをください」っていうのが望みなんだなと。
まあ、そのわりにATOK-Xをまともに使ったことがないのはしばらくVine Linuxでkinput2&Wnn7でくらしてたからか。
今使ってるノートPCにはTurbolinuxを入れてあるものの、設定が面倒でほとんど使ってないしなぁ。
とりあえず、久々にxwnmoでも使ってみるか。そのためにはebuildをでっち上げないと。
昔はQtと相性が悪かったり、キーバインドがkinput2とは違うのが慣れなかったりで使うのをやめたはずだが、いまだとどんなものだろう。
10月 182004
少し前に読んだ内容ですが、kzk氏の日記経由でいくや氏の「Linuxにおける日本語環境の現状」とその補足。
こういうのを見て思うのだが、XIMを捨て去りたい人の説明できちんとしたものってなかなか見ないんだよなぁ。自己完結してて他人に伝わってないのか、言葉が足りないなと思うものが多い。
いくや氏の論もXIMというプロトコルの問題なのか、kinput2というXIMサーバの問題なのかの切り分けが(本人には出来ているのかもしれないが)外からはわかりにくいと思う。
kinput2は十分な機能を持ったものではないし、XIMにも問題点があるのは確かだが、XIMを切り捨てられるだけのものが現状は一切ないのも明らかだと思う。
10月 172004
夏のボーナスでノートPCを購入してから、家でネットを見たりするメインがそっちのマシンに移りつつあるんだけど、メールをMS-Windowsで見るのはまだ抵抗感あるし、何より大量のメールデータを移動する気にもなれなくてどうしようかなといろいろ検討中。
とりあえず、IMAPサーバを導入してみることに。
Gentoo Linuxでexpectがコンパイルできないバグにひっかかって今まで導入してなかったんだけど、それを適当なパッチで乗り切ってcourier-IMAPを導入。
ちなみに、ネットで検索するとpostfix+procmail+fetchmail+IMAPという組み合わせが良く書いてあるけど、メールを出すほうはプロバイダに直接つないでるのでpostfixは入れず。
IMAPサーバを起動してつなぐだけでfetchmailで取り込んだメールがMS-WindowsのMozilla Thunderbirdで読めるのを確認。これだけでもかなり楽になるな。
あとはメールの振り分けとかなんだが、それをやろうとするとprocmailのルールファイルをいろいろいじる必要があるからなぁ。いまkmailでフィルタを使って快適に振り分けしてるからそれを使いたいところだが。
あとは外部のネットワークからメールを見る方法を何とかしたいなぁ。そういうのを考えると持ち出しも出来るノートPCのほうにメールを移すのが楽なんだろうが。
6月 142004
私の今のメインマシンはMS-Windows XPとGentoo Linuxのデュアルブートにしてありますが、一週間ほど前、Linuxの調子が悪くなり、XPもブートしなくなり、とうとう全システムの再インストールをしました。
完全復活にはもう少しかかりそうですが、ようやくだいたいのことは動作する状態に戻ったので久々にエントリー。
ちなみに、システムを壊したのはおそらくLinux。原因は私の操作ミスではありますが、まさかこんなことになろうとは。
5月 182004
uim系のIMを使ったことがないだけじゃ、あれなんで、そのうち使ってみるとして、まずはソースを軽く読んでみることにした。知らないままにいろいろ書いても仕方がない。
まずは変換エンジンの切り替え関連。
Cのソースはuim直下。scheme系はscm直下にあるのか。簡単な変換はschemeだけで実装して、複雑なものはCの方でライブラリを読むと。
だが、この作りだと、変換エンジンがpluggableにはなってないようだ。新たに(複雑な)変換エンジンを作っても、uimの再コンパイルがいるのか。この辺りのインターフェースは中途半端だな。Anthyはどうせuim専用みたいなものなんだから、uimのソースにAnthyに依存する部分なんかなくてもすむような作りにしておいた方がいいだろうに。
ところで、uimはライブラリでのIMの実装であるため、Anthyなどもライブラリの形で実装されているようだ。(こちらのソースは未読)
ということは辞書は複数プロセスのメモリ空間に読み込まれる?辞書の学習内容のプロセス間の同期はどうなってる?
と思ったら、anthy-agentとか、anghy-dic-toolとかあるのか。この辺、内部構造をまた調べておこう。
さて、uimに戻るけど、全体的な構造としては、ライブラリでの実装にするツケがヘルパーアプリやanthyのコマンドとかに出てきていると言えるのだろうか。このあたりはもうすこしよく勉強してからか。
とりあえず、気になった点。コーディングしている人が、get_c_string()関数の仕様をよく把握していないような。
たとえば、uim-util.cの「return strdup(get_c_string((LISP)str));」なんてのはもろメモリーリークに繋がるコーディングだし、
uim-func.cのim_register_im()あたりも動作的には問題なさそうだが、効率的には気になるなぁ。まあ、こちらはそうたくさん呼ばれる関数ではなさそうなのでパフォーマンスにも大きな影響はないだろうけど。
5月 162004
gtk+のimmoduleに続き、Qtにもimmoduleを実装しようという動きがある。
これでgtk+, QtというX11向けの二大ToolkitにInput Methodの動的切り替えの機能が実装されていくわけだが、個人的な考えとしてはこれらは技術的には面白いものの、ユーザのためになる機能なのかということに関しては疑問点を持たざるを得ない。
というのは、次のような問題があるからである。
* gtk+, Qtではそれぞれimmoduleと名前がついているにも関わらず、両者に互換性はない。
* そのため、それぞれ別々に設定が必要である。
* IMの動的切り替え機構はToolkitへの実装であるため、変更作業は基本的にアプリケーション単位である。ユーザーは多くの場合デスクトップ環境単位での切り替えを望むと考えるため、そのための機構の実装か、デスクトップの再起動が必要となる。
こういうことを考えていくと、最終的にはToolkitの外での統一的なIM-APIと、IMマネージャというべきアプリの作成が必要なのだろうと思う。もっとも、IM-APIとしてはIIIMFやuimがそれとなろうとしていたのだろうが、両者にはその作業をするという雰囲気が感じられない。IMの決定打がないがためのimmoduleなのだろうが、ユーザの使い勝手のアプローチもない状態で、今後新しい実装の出現がないことを祈る。
5月 162004
XIM, IIIMF, uimとX11用のInput Methodにはいくつかあるものの、どうもそれらの差がよくわかってない。
XIMはだめなものとして、IIIMF, uimが出てきているとはわかるのだが、具体的にそれらの利点がよくわからないし、XIMではなく、IIIMFやuimにnativeに対応していこうという動きももう一つ見えない。
今ところ、X11関係はimmoduleに向かっていっているようだけれど、それの是非はともかく、IMについてまとめてみることにした。
なお、利用経験はXIMのみ。IIIMF, uimについてはWebで検索した結果からの推測となる。不明点も多く、誤解している点もあると思うので指摘をいただけるとありがたい。
3月 082004