アカウント名:
パスワード:
ですので、SCIMはXIMの上位というよりは、XIMのレイヤーも含んでいて、将来的にはXIMに置き換わろうとしているのではないでしょうか。
で、ポストXIMの座を狙っているIIIMF、uim、immoduleなどとは競合する位置づけにあるのではないかと。
いや、担当する範囲って言っても、従来までは
アプリからインプットメソッドを使うためのAPI
すみません、これがよく分からないです。インプットメソッドというのは、アプリ側から使うものではなく、逆に、インプットメソッドの存在を意識しないような作り方をしたアプリであってもインプットメソッドが使え
すみません、これがよく分からないです。インプットメソッドというのは、アプリ側から使うものではなく、逆に、インプットメソッドの存在を意識しないような作り方をしたアプリであってもインプットメソッドが使えるようになっていくべきなのではないでしょうか。たとえばGTK2みたいに。
このとき、従来ならXIMに対応するように頼むとかXIM対応パッチを書くとかすればよかったのですが、今後はどうすればいいのでしょうか?
それから、APIは狭義のSCIMには含まれていないかもしれませんが、広義の(システムとしての)SCIMには含まれているのではないでしょうか?#61 [srad.jp]
基本的にはXIMへの対応は必須でしょう。kinput2+cannaでもanthy+uimでも入力できますから。従って
が無難かと思われます。
別ACもおっしゃる通りSCIMとuimは別のプロジェクトです。「なにか協力できるところないか?」というような話も出ていましたが、少なくともコードベースは相当に異なるので、協力できる範囲そのものはあまり広くはなさそうです。
ユーザーから見た使い勝手を考えたとき、別プロジェクトだから、という理由はどうでもいいことです。SCIMとuimはそれぞれに存在意義があり、両者を同時に使ったり、場面によって使い分けたりする必要があるということを、ユーザーに説明することはできるでしょうか? (日本
canna、skk とは別レイヤーですので競合しません。それは、canna と XIM が従来にも競合しなかったのと同じです。
入力方法というか変換エンジン (canna、skk など) は、言語や好みに応じて豊富な選択肢から選べるようになっているべきです。ところが、アプリケーションが直接変換エンジンに接続する方法だと、アプリケーション開発者への負担が大きいため、けっきょく変換エンジンはわずかなアプリケーションでしか利用できないことになってしまいますので。それに、全世界の言語の知識を、個々のアプリケーション開発者が持っていないといけなくなります。そこで、変換エンジンとアプリケーションのあいだにレイヤーを追加するのがよい、ということになります。SCIM、IIIMF、uim、immodule、XIM がこれに相当します。
というのは、scimを認めたらuimの必要性はなくなってしまうんじゃないかなと思いまして。
記事だとuimは2の部分(プリエディット制御)に重点を置いているといいますが、uimは別途cannaやwnnなどの1の部分(変換エンジン)を必要とします。で、cannaやwnnは2の部分も持ってるわけだから、じゃあuimをなくしてscimから直接cannaやwnnに接続したほうがシンプルだね、となりそうです。
入力システムの概要 [sourceforge.jp]というML
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
位置づけ (スコア:0)
それぞれの関係をわかりやすく示した図とかってないですかねぇ?ぐぐれ?そりゃそうだがSCIMまで含まれたものはないなぁ。
Re:位置づけ (スコア:5, 参考になる)
scimは、uimを使います。(uimが対応する変換エンジンとuim経由で接続します。)
scimは、lib-m17nも使います。(lib-m17nが対応する変換エンジンとlib-m17n経由で接続します。
scimは、cannaやskkを使います。(これらの変換エンジンにはuim経由で接続します。)
scimは、XIMで喋ります。(XIMに対応したアプリケーションとやりとりします。kinput2やuim-ximの実装と競合します。ただし、kinput2+wnnとは競合しません。)
scimは、immoduleで喋ります。(immoduleに対応したアプリケーションとやりとりします。uimのimmodule接続部分の実装と競合します。)
# ザッと見て回ると多分こんな感じっぽいですが、間違ってたら誰かツッコミ入れて下さい。
# 「競合」の意味は非常に狭く取ってます。skkの実装も複数ありそうな気がしますが、詳しくないので触れません。
Re:位置づけ (スコア:2, 参考になる)
純粋なフロントエンドのみで。
わたしは最近Anthy+uim使ってるんですが、「かな」にならないローマ字入力が消えちゃうために、かなモードのままで英数入力出来なくて嫌なので試してみようかと思っています。
Re:位置づけ (スコア:1, 参考になる)
Re:位置づけ (スコア:0)
ですので、SCIMはXIMの上位というよりは、XIMのレイヤーも含んでいて、将来的にはXIMに置き換わろうとしているのではないでしょうか。
で、ポストXIMの座を狙っているIIIMF、uim、immoduleなどとは競合する位置づけにあるのではないかと。
いや、担当する範囲って言っても、従来までは
Re:位置づけ (スコア:1, 参考になる)
レイヤ分けについてもいろいろ考えてみましたが、これについては別件でコメントします。
Re:位置づけ (スコア:0)
すみません、これがよく分からないです。インプットメソッドというのは、アプリ側から使うものではなく、逆に、インプットメソッドの存在を意識しないような作り方をしたアプリであってもインプットメソッドが使え
Re:位置づけ (スコア:1, 参考になる)
「アプリからインプットメソッドを使うためのAPI」をいくつか以下に示しておきます。
Re:位置づけ (スコア:0)
このとき、従来ならXIMに対応するように頼むとかXIM対応パッチを書くとかすればよかったのですが、今後はどうすればいいのでしょうか?
それから、APIは狭義のSCIMには含まれていないかもしれませんが、広義の(システムとしての)SCIMには含まれているのではないでしょうか?#61 [srad.jp]
Re:位置づけ (スコア:0)
Re:位置づけ (スコア:0)
基本的にはXIMへの対応は必須でしょう。kinput2+cannaでもanthy+uimでも入力できますから。従って
が無難かと思われます。
Re:位置づけ (スコア:0)
ユーザーから見た使い勝手を考えたとき、別プロジェクトだから、という理由はどうでもいいことです。SCIMとuimはそれぞれに存在意義があり、両者を同時に使ったり、場面によって使い分けたりする必要があるということを、ユーザーに説明することはできるでしょうか? (日本
Re:ええのんあったで~ (スコア:1)
Re:位置づけ (スコア:1, 参考になる)
canna、skk とは別レイヤーですので競合しません。それは、canna と XIM が従来にも競合しなかったのと同じです。
入力方法というか変換エンジン (canna、skk など) は、言語や好みに応じて豊富な選択肢から選べるようになっているべきです。ところが、アプリケーションが直接変換エンジンに接続する方法だと、アプリケーション開発者への負担が大きいため、けっきょく変換エンジンはわずかなアプリケーションでしか利用できないことになってしまいますので。それに、全世界の言語の知識を、個々のアプリケーション開発者が持っていないといけなくなります。そこで、変換エンジンとアプリケーションのあいだにレイヤーを追加するのがよい、ということになります。SCIM、IIIMF、uim、immodule、XIM がこれに相当します。
Re:位置づけ (スコア:0)
Re:位置づけ (スコア:1, 参考になる)
scimに限らず、ここらへんの位置づけについては、 入力システムの概要 [osdn.jp]というMLの投稿記事があります。御参考までに。
Re:位置づけ (スコア:1, 興味深い)
というのは、scimを認めたらuimの必要性はなくなってしまうんじゃないかなと思いまして。
記事だとuimは2の部分(プリエディット制御)に重点を置いているといいますが、uimは別途cannaやwnnなどの1の部分(変換エンジン)を必要とします。で、cannaやwnnは2の部分も持ってるわけだから、じゃあuimをなくしてscimから直接cannaやwnnに接続したほうがシンプルだね、となりそうです。
Re:位置づけ (スコア:0)
Re:位置づけ (スコア:0)