At Thu, 11 Dec 2003 00:09:28 +0900,
Takashi SAKAMOTO wrote:
> >   そういった単純な変換機能も提供した上でなおかつ、API を抽象化して変換
> > エンジンに依存せずにそれらを利用可能にするものが uim、だと理解しています。
> 
> 私はその API こそが重要であり、その部分の層を厚くすることは alternative
> の登場を妨げるのではないか、と思っています。

  ここでいう alternative は何に対してのものでしょうか。変換エンジンで
しょうか。もしそうだとすると、なぜそれが妨げる理由につながるのか、ちょっ
とよくわかりません。

> >   実は BSD/Linux Day の発表に合わせて、tty ベースで uim を動作させる実
> > 装を作ってみたのですが、だいたい 2日ぐらいの負荷で完成できました。昔似
> > たことを ONEW でやったときには1週間ちょっとかかったのですが、素性の良
> > い API の整備は重要なことだと思います。
> >
> > http://www.daionet.gr.jp/~knok/screen/uim.html
> >
> > # しかし時間がなくてお披露目するチャンスはありませんでしたが...
> 
> はい、そのページは既に拝見しています。が、それがもし gtk immodule のよう
> なもので動作できるとすればどうでしょうか？

  immodule と tty を繋ぐようなものができるかどうか、という話でしょうか。
実のところ immodule の仕組みもよくわかってないので可能かどうかはわかり
ません。

> >   そのあたり、きっと Windows は多分良くできた framework があるんだろう
> > なあと想像しています。
> 
> Windows の実装は immodule に近いと思います。(IME は API の定義、
> API の実装は dll によって自由に切り替えられる)

  なるほど、そうなんですか。

  会場では SKK を使っているという話をしたのですが、実はずいぶん前に 
Anthy へ移行しようとして、変換効率とかそういったところとはまったく関係
ない理由で挫折し、いまに至っています。その問題はいまは解決されているの
で、昨日から anthy を再度使いはじめています。

# というわけでこの記事も Powerd by anthy.
-- 
野首 貴嗣
E-mail: knok@daionet.gr.jp
        knok@namazu.org / knok@debian.org