YamaKen
yamak****@bp*****
2005年 10月 22日 (土) 15:10:59 JST
こんにちは。ヤマケンです。 At Sat, 22 Oct 2005 14:05:22 +0900, ek.ka****@gmail***** wrote: > > 05/10/21 に YamaKen<yamak****@bp*****> さんは書きました: > > context configuration changedあたりの名前で通知してからクライア > > ント自身に言語やエンコーディングを取得させる形でAPI案を作ってみ > > てもらえますか? > > configuration changed ですか。そこまで一般化して考えていませんで > した。configuration というと、どんなものがありますか? できれば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 改訂も巻き込んでしまって大事になるので、現時点では加藤さん案がバ ランスが取れていてよいと思います。 ------------------------------- ヤマケン yamak****@bp*****
