Etsushi Kato
ek.ka****@gmail*****
2005年 10月 22日 (土) 19:31:56 JST
05/10/22 に YamaKen<yamak****@bp*****> さんは書きました: > できればcomposerフレームワークにもAPIを引き継ぎたいので無理のな > い範囲で一般化できると嬉しいです。context固有の構成情報としては > 以下のものが対象になります。 > > - locale (言語/エンコーディング) > - idname (composer ≒ IM のクラス識別名) > - indication (アイコン、label、short-desc) > > 他の構成情報、例えば候補ウィンドウの諸元等は別系統のcallbackで処 > 理する事になります。 > > > こちらでは、context の IM の名前を通知するだけのものを想像して > > いました。libuim にl > > uim_set_im_switched_cb(uim_context uc, > > void (*im_switched_cb)(void *ptr, const char *engine)); > > を追加して、必要なブリッジではそれを使って callback 関数を登録させ > > 通知を受けたブリッジにおいて独自に IM の名前からいろいろ必要な > > 作業をするという感じです。 > > 私もインタフェイスの基本方針はそれがよいと思います。ただ、 > "im_switch"という特定用途向けの名前を付ける事は避けたいです。 > > これはIM switchingなしに単体のIMが複数の言語を切り換えながら使う > ようなケースを想定しています。例えばzh_CNとzh_TW等。クライアント > が言語情報を扱える場合は十分にありえる話です。 > > できればengine引数も無くしてクライアントが別APIを使って自前で取 > 得するようにしたいところですが、それだとuim_get_im_name()等のAPI > 改訂も巻き込んでしまって大事になるので、現時点では加藤さん案がバ > ランスが取れていてよいと思います。 そうですね。今の、 IM を nth を使って呼びだす API だと使いにくい ので、一般化はやりにくいなと思っていました。 ただ、良く考えたら uim_get_current_im_name() は API の改訂無 しに使えるので、やはり engine 引数は無しにして、 uim_set_configuration_changed_cb(uim_context uc, void (*changed_cb)(void *ptr)); にしてみます。これなら、後々の API の拡張や composer の導入でも 引き続き使えますよね。 -- Etsushi Kato ek.ka****@gmail*****
