SCIM 1.0.0 リリース 43
ストーリー by yoosee
ここまできた！ 部門より
ここまできた！ 部門より
Anonymous Coward曰く、"9月4日付でSCIM (Smart Common Input Method platform)のバージョン1.0.0がリリースされました。これはUNIX上における快適な入力環境の実現、およびインプットメソッドの開発を簡潔にするためのフレームワークで、C++によるオブジェクト指向なデザインを採用し、様々なコンポーネントが動的モジュール化されているのが特徴です。開発者から見た利点としては、IMEngineと呼ばれるプラグインを書いて(再コンパイルなしに)様々な言語に対応できる点が挙げられるでしょう。現在入手できるIMEngineには以下のものがあります。
- scim-tables(テーブルベースのインプットメソッド。CJK、アムハラ語、ロシア語のデータが含まれる)
- scim-chinese(ピンイン入力による簡体字中国語のインプットメソッド)
- scim-hangul(韓国語のインプットメソッド)
- scim-uim(uimのブリッジ。uimがサポートするインプットメソッドが利用できる)
- scim-m17n(m17n-libのブリッジ。m17n-libがサポートするインプットメソッドが利用できる)
またXIMだけでなくgtk-immoduleや開発中のimmodule for Qtにも対応しているので(IIIMFへの対応も予定されている)、インプットメソッド開発者が個別に実装する手間もなくなります。
一方、エンドユーザにとっての利点ですが、Gtk+によるユーザーフレンドリーなGUI(ツールバー、候補ウインドウ、設定ツール)が用意されていて、WindowsやMacからLinuxに乗り換えた人でもさほど違和感なく使える点が挙げられると思います。KDEな人向けにはskimがありますので、 代わりにそちらを使ってみてください。"
これは (スコア:3, 興味深い)
Re:これは (スコア:5, 参考になる)
↑ (スコア:0)
Re:これは (スコア:0)
ATOKとの組み合わせは？ (スコア:2, 参考になる)
んです。
さりとて自分で何とかする能力もありませんし、ATOK for Linux
を購入してインストールしたんです。
確かに変換エンジンの能力に関する不満はほぼ解消されたのです
が、フロントエンド（というのかな？とにかく目に見える部分）
にどうも違和感が残ってしまって、悶々としていたんです。
skimとATOKの変換エンジンの組み合わせが実現すれば、本当に
うれしいです。
日本のLinux普及にもはずみがつくでしょう。
Re:ATOKとの組み合わせは？ (スコア:2, すばらしい洞察)
具体的にどんな所でしょうか。こういうのは、黙って待っていても実現しないので、声をあげることも大切だと思います。プロジェクトごとにポリシーは様々でしょうが、メーリングリストに投げてみるとか、バグトラッキングシステムにRFE(Request for Enhancement)で登録するとか。
いや、開発に係わっていない私が言っても説得力ないですけど……「初心者」にもできる貢献ということで。
Re:ATOKとの組み合わせは？ (スコア:2, 興味深い)
そういうものはバグとして報告しにくいし、そもそも説明が難しいでしょう。
プログラマ的にはこれでよし、と言えるものでも、クライアントサイドでは表現しにくいフィーリングによる不満があったりするわけですよね。
オープンソースの開発手法では、そういう不満を汲み取るのは難しいでしょうね。
ATOKのほうはそういう不満を受け取り、解決していく姿勢はあるようなので、次のバージョンでは元発言者さんが感じたような違和感は無くなってるかもしれないですね。
Re:ATOKとの組み合わせは？ (スコア:1)
RFEを許容するかどうかはいろいろでしょう。「プロジェクトごとにポリシーは様々でしょうが」と書いたとおり。それを許容するプロジェクトもあるし、許容しないプロジェクトもある。
# RFEなんていう言葉があるくらいですから、珍しくはない。
で、
とは、(オープンソースの開発手法なんて様々、というのは置いておくとして)なぜATOKでは受け取れてオープンソースでは受け取れないのでしょう。ATOKの開発陣に説明できるなら、オープンソースの開発陣にも説明できますよね。
受け入れる側の問題?それならやっぱり、オープンソースプロジェクトごとに千差万別、としか言えませんが。
# 「こんな機能を開発しろ」と押し付けろ、に解釈されたのかな。
Re:ATOKとの組み合わせは？ (スコア:1)
言葉にできない違和感をエンジニアにわかりやすく説明できる人というのは、それだけでもうプロフェッショナルでしょうね。
そういう意味では受け取る側の問題とも言えますし、そうではないとも言えるでしょう。
「なんか見た目が変。うまく言えないけどなんか違う」
こんなバグ報告なりRFEなりを受け入れられるオープンソースプロジェクトというのは、ちょっと見たことがないですね。
もしあるのならぜひ教えてください。
Re:ATOKとの組み合わせは？ (スコア:0)
ユーザーは「困っているけど、自分が何に困っているのか明確にできない」っていうことが結構ありますからね。
企業だと開発者とは別に漠然としたユーザーの不満を具体的なものとして引き出す専門家がいたりします。
Re:ATOKとの組み合わせは？ (スコア:0)
あるような、ないような。
各種BTSがそんな役割を持っていることはあります。
Re:ATOKとの組み合わせは？ (スコア:0)
Re:理想ばかりでは逆効果なり (スコア:0)
ガッカリする可能性も高いけどね。
特に、見た目にwinと違和感がーてな問題に執着しているような
プロジェクトってあんまり無かったと思う。
偽造キーイベント (スコア:1)
MS-Winなら簡単に出来るけど……
できるようならキーカスタマイズソフト移植したいなぁ。
Re:偽造キーイベント (スコア:4, 参考になる)
どちらもルート権限が必要ですが、uinputデバイスが使えれば一般ユーザー権限でデバイスを作ることができます。
詳しくは
linux kernel の Documentation/input/
http://www.linuxjournal.com/article.php?sid=6429
http://geekounet.org/powerbook/ の mouseemu
http://navi.cx/svn/misc/trunk/vision/lib/uinput_mouse.c
等を参照してください。
ルートになれて、USBキーボードが繋がれているのなら/dev/input/eventの書き込みパーミッションを開けておき、イベントをgrabして加工して書き戻すのが一番楽だと思われます。(mouseemu参照)
Re:偽造キーイベント (スコア:0)
Re:偽造キーイベント (スコア:2, 参考になる)
> かな？
できます。
しかし、X client によっては、他の X client から送られてきた
キーイベントを無視するものがあります。
たとえば xterm なんかもそうです。もっとも allowSendEvents
リソースで、無視しないように設定できますが…
位置づけ (スコア: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)
なんだか色々ややこしいな (スコア:0)
あと、C++ じゃないと駄目なの？
Re:なんだか色々ややこしいな (スコア:0)
skkinput,kinput2みたいなものとはちがうんでしょ?
親指シフト (スコア:0)
Re:同時打鍵入力 (スコア:1)
ローマ字入力モードの場合は、限定的な同時打鍵は出来る
KA→か と AK→か のように、逆順もローマ字表に登録します
ローマ字かな変換のアルゴリズムの制約によります
母音がAIUEO固定とか Y、M 、N などが固定処理されていると
できませんが。
Re:同時打鍵入力 (スコア:0)
限定的というのは、少々つらいですね。
一般的な PC のキーボードで親指シフトする場合、同時打鍵に使用する右シフトと左シフトキーには、"変換" "無変換" "空白" のキーのいずれか二つを使うことになると思います。ここで仮に左シフトに "空白" を、右シフトに"変換"を使うことを考えます。 するとキーの "s" を押した場合次のように出力する必要があります。
どのＬＯＣＡＬＥでも (スコア:0)