パスワードを忘れた? アカウント作成
8856 story

SCIM 1.0.0 リリース 43

ストーリー by yoosee
ここまできた! 部門より

Anonymous Coward曰く、"9月4日付でSCIM (Smart Common Input Method platform)のバージョン1.0.0がリリースされました。これはUNIX上における快適な入力環境の実現、およびインプットメソッドの開発を簡潔にするためのフレームワークで、C++によるオブジェクト指向なデザインを採用し、様々なコンポーネントが動的モジュール化されているのが特徴です。開発者から見た利点としては、IMEngineと呼ばれるプラグインを書いて(再コンパイルなしに)様々な言語に対応できる点が挙げられるでしょう。現在入手できるIMEngineには以下のものがあります。


またXIMだけでなくgtk-immoduleや開発中のimmodule for Qtにも対応しているので(IIIMFへの対応も予定されている)、インプットメソッド開発者が個別に実装する手間もなくなります。

一方、エンドユーザにとっての利点ですが、Gtk+によるユーザーフレンドリーなGUI(ツールバー、候補ウインドウ、設定ツール)が用意されていて、WindowsやMacからLinuxに乗り換えた人でもさほど違和感なく使える点が挙げられると思います。KDEな人向けにはskimがありますので、 代わりにそちらを使ってみてください。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • これは (スコア:3, 興味深い)

    by Anonymous Coward on 2004年09月05日 14時09分 (#617447)
    コンソールからの入力にも使えるんだろうか?
  • by Anonymous Coward on 2004年09月05日 16時47分 (#617488)
    Linux初心者で日本語入力だけはどうしても慣れなくて不満だった
    んです。
    さりとて自分で何とかする能力もありませんし、ATOK for Linux
    を購入してインストールしたんです。
    確かに変換エンジンの能力に関する不満はほぼ解消されたのです
    が、フロントエンド(というのかな?とにかく目に見える部分)
    にどうも違和感が残ってしまって、悶々としていたんです。
    skimとATOKの変換エンジンの組み合わせが実現すれば、本当に
    うれしいです。
    日本のLinux普及にもはずみがつくでしょう。
    • by mocona (23547) on 2004年09月05日 18時13分 (#617498)

      確かに変換エンジンの能力に関する不満はほぼ解消されたのです
      が、フロントエンド(というのかな?とにかく目に見える部分)
      にどうも違和感が残ってしまって、悶々としていたんです。

      具体的にどんな所でしょうか。こういうのは、黙って待っていても実現しないので、声をあげることも大切だと思います。プロジェクトごとにポリシーは様々でしょうが、メーリングリストに投げてみるとか、バグトラッキングシステムにRFE(Request for Enhancement)で登録するとか。

      いや、開発に係わっていない私が言っても説得力ないですけど……「初心者」にもできる貢献ということで。
      親コメント
      • フィーリングの善し悪しの問題なんじゃないんですか?
        そういうものはバグとして報告しにくいし、そもそも説明が難しいでしょう。

        プログラマ的にはこれでよし、と言えるものでも、クライアントサイドでは表現しにくいフィーリングによる不満があったりするわけですよね。
        オープンソースの開発手法では、そういう不満を汲み取るのは難しいでしょうね。

        ATOKのほうはそういう不満を受け取り、解決していく姿勢はあるようなので、次のバージョンでは元発言者さんが感じたような違和感は無くなってるかもしれないですね。
        親コメント

        • そういうものはバグとして報告しにくいし、そもそも説明が難しいでしょう。

          RFEを許容するかどうかはいろいろでしょう。「プロジェクトごとにポリシーは様々でしょうが」と書いたとおり。それを許容するプロジェクトもあるし、許容しないプロジェクトもある。

          # RFEなんていう言葉があるくらいですから、珍しくはない。

          オープンソースの開発手法では、そういう不満を汲み取るのは難しいでしょうね。

          で、

          ATOKのほうはそういう不満を受け取り、解決していく姿勢はあるようなので

          とは、(オープンソースの開発手法なんて様々、というのは置いておくとして)なぜATOKでは受け取れてオープンソースでは受け取れないのでしょう。ATOKの開発陣に説明できるなら、オープンソースの開発陣にも説明できますよね。

          受け入れる側の問題?それならやっぱり、オープンソースプロジェクトごとに千差万別、としか言えませんが。

          # 「こんな機能を開発しろ」と押し付けろ、に解釈されたのかな。
          親コメント
          • ATOKが受け取れるであろうと推測したのは、エンドユーザーの持つフィーリングに長年鍛えられているからですね。
            言葉にできない違和感をエンジニアにわかりやすく説明できる人というのは、それだけでもうプロフェッショナルでしょうね。

            そういう意味では受け取る側の問題とも言えますし、そうではないとも言えるでしょう。

            「なんか見た目が変。うまく言えないけどなんか違う」

            こんなバグ報告なりRFEなりを受け入れられるオープンソースプロジェクトというのは、ちょっと見たことがないですね。
            もしあるのならぜひ教えてください。
            親コメント
          • 説明ですか、うーん。
            ユーザーは「困っているけど、自分が何に困っているのか明確にできない」っていうことが結構ありますからね。
            企業だと開発者とは別に漠然としたユーザーの不満を具体的なものとして引き出す専門家がいたりします。
            • > このユーザーの漠然とした要求を引き出すというプロセスが、現在オープンソースの開発手法に組み入れられていることが少ないってことじゃないですか?

              あるような、ないような。
              各種BTSがそんな役割を持っていることはあります。
      • 元の文を書いた人とは別人ですが、簡単に言うと、WindowsのATOKやIMEぐらいのGUI環境は実現して欲しいです。
      • 声を上げてみても、やんわりと否定されちゃったりして
        ガッカリする可能性も高いけどね。
        特に、見た目にwinと違和感がーてな問題に執着しているような
        プロジェクトってあんまり無かったと思う。
  • by fiercewinds (22740) on 2004年09月05日 21時46分 (#617564) 日記
    Unixってあまり詳しく無いんだけど、キーイベントって発行できるのかな?
    MS-Winなら簡単に出来るけど……

    できるようならキーカスタマイズソフト移植したいなぁ。
    • by ruto (17678) on 2004年09月06日 0時32分 (#617631) 日記
      Input Subsystemを使って仮想のデバイスドライバを書いたり、既存のUSBキーボードの/dev/input/eventに書き込んだりといった方法があります。
      どちらもルート権限が必要ですが、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参照)
      親コメント
    • by Anonymous Coward on 2004年09月05日 22時17分 (#617576)
      > Unixってあまり詳しく無いんだけど、キーイベントって発行できるの
      > かな?

      できます。
      しかし、X client によっては、他の X client から送られてきた
      キーイベントを無視するものがあります。
      たとえば xterm なんかもそうです。もっとも allowSendEvents
      リソースで、無視しないように設定できますが…
      親コメント
  • by Anonymous Coward on 2004年09月05日 14時14分 (#617450)
    競合するものは何になるんでしょう?IIIMF?uim?XIM?canna?skk?immodule?

    それぞれの関係をわかりやすく示した図とかってないですかねぇ?ぐぐれ?そりゃそうだがSCIMまで含まれたものはないなぁ。
    • Re:位置づけ (スコア:5, 参考になる)

      by Anonymous Coward on 2004年09月05日 16時07分 (#617479)
      scimは、まだ、IIIMFを使えません。(IIIMFで接続する変換エンジンを使えません。IIIMFに対応したアプリケーションとやりとりできません。)

      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, 参考になる)

      by kamakama (18535) on 2004年09月05日 15時23分 (#617467)
      タレコミみたところでは、変換エンジンへの直接接続する機能は持ってないようにみえますね。
      純粋なフロントエンドのみで。

      わたしは最近Anthy+uim使ってるんですが、「かな」にならないローマ字入力が消えちゃうために、かなモードのままで英数入力出来なくて嫌なので試してみようかと思っています。
      親コメント
    • Re:位置づけ (スコア:1, 参考になる)

      by Anonymous Coward on 2004年09月05日 17時25分 (#617492)
      SCIMはXIM、IIIMF、あるいはGUIツールキット固有のAPIなどよりも上位のレイヤに位置付けられています。あるいはこれらのラッパーと言ってもよいのかもしれません。ただIIIMFやuimとは担当する範囲が相当かぶっているのも事実ですが。
      親コメント
      • by Anonymous Coward
        現状ではXIMのラッパー(としても使える)ですが、それは、従来まではXIMサーバーがよく用いられてきたということから、スムーズに移行できるようにとのことだと思います。

        ですので、SCIMはXIMの上位というよりは、XIMのレイヤーも含んでいて、将来的にはXIMに置き換わろうとしているのではないでしょうか。

        で、ポストXIMの座を狙っているIIIMF、uim、immoduleなどとは競合する位置づけにあるのではないかと。

        いや、担当する範囲って言っても、従来までは

        • Re:位置づけ (スコア:1, 参考になる)

          by Anonymous Coward on 2004年09月06日 15時09分 (#617809)
          ですので、SCIMはXIMの上位というよりは、XIMのレイヤーも含んでいて、将来的にはXIMに置き換わろうとしているのではないでしょうか。
          重要な点を見落としていると思います。アプリからインプットメソッドを使うためのAPIをSCIMは自前では用意していないのです。ここがIIIMFやuimと決定的に違う点です。

          レイヤ分けについてもいろいろ考えてみましたが、これについては別件でコメントします。
          親コメント
          • by Anonymous Coward

            アプリからインプットメソッドを使うためのAPI

            すみません、これがよく分からないです。インプットメソッドというのは、アプリ側から使うものではなく、逆に、インプットメソッドの存在を意識しないような作り方をしたアプリであってもインプットメソッドが使え

            • Re:位置づけ (スコア:1, 参考になる)

              by Anonymous Coward on 2004年09月07日 14時32分 (#618364)
              すみません、これがよく分からないです。インプットメソッドというのは、アプリ側から使うものではなく、逆に、インプットメソッドの存在を意識しないような作り方をしたアプリであってもインプットメソッドが使えるようになっていくべきなのではないでしょうか。たとえばGTK2みたいに。
              意識しなくて済むようになっているのはGtk+2のウィジェット内部でAPIにアクセスして必要な処理を行ってくれているからです。自分でウィジェットを作ったりする場合には同様の処理を自分で書く必要が出てくることもあるでしょう(参考:GtkIMContextの使い方 [osdn.jp])。

              「アプリからインプットメソッドを使うためのAPI」をいくつか以下に示しておきます。
              親コメント
              • by Anonymous Coward
                外国産のソフトがあって、すごくいいんだけど日本語入力ができないために使い物にならない、というのがあったとします。そういうとき、日本語入力に対応するように作者に頼むとか、パッチを書いて送るとかするとみんなが幸せになれますよね。

                このとき、従来ならXIMに対応するように頼むとかXIM対応パッチを書くとかすればよかったのですが、今後はどうすればいいのでしょうか?

                それから、APIは狭義のSCIMには含まれていないかもしれませんが、広義の(システムとしての)SCIMには含まれているのではないでしょうか?#61 [srad.jp]

              • by Anonymous Coward
                SCIMとuimは別のプロジェクトですが……。
              • by Anonymous Coward

                このとき、従来ならXIMに対応するように頼むとかXIM対応パッチを書くとかすればよかったのですが、今後はどうすればいいのでしょうか?

                基本的にはXIMへの対応は必須でしょう。kinput2+cannaでもanthy+uimでも入力できますから。従って

                • Gtk+2アプリならGtkIMContextを使ったコードを書く。
                • Qt3ではimmodule for Qtはアドオンなので従来通りの方針で。 Qt4でimmodule for Qtネイティブに移行する。
                • その他のXアプリも従来通りXIMベースで。 オプションとしてxiiimp.soを使う(e.g. OOo)とかlibuimを使う(e.g. mlterm)のはアリ。

                が無難かと思われます。

              • by Anonymous Coward
                詳しい説明ありがとうございます。

                別ACもおっしゃる通りSCIMとuimは別のプロジェクトです。「なにか協力できるところないか?」というような話も出ていましたが、少なくともコードベースは相当に異なるので、協力できる範囲そのものはあまり広くはなさそうです。

                ユーザーから見た使い勝手を考えたとき、別プロジェクトだから、という理由はどうでもいいことです。SCIMとuimはそれぞれに存在意義があり、両者を同時に使ったり、場面によって使い分けたりする必要があるということを、ユーザーに説明することはできるでしょうか? (日本

    • by kamakama (18535) on 2004年09月05日 22時39分 (#617582)
      http://freedesktop.org/pipermail/uim/attachments/20040811/023d6030/scim-uim-0001.pdf
      親コメント
    • Re:位置づけ (スコア:1, 参考になる)

      by Anonymous Coward on 2004年09月06日 9時45分 (#617709)
      IIIMF、uim、SCIM、immodule はそれぞれ、既存入力システム (XIM) の置き換えを目指していると思います。そういう意味で、これらは競合すると思います。

      canna、skk とは別レイヤーですので競合しません。それは、canna と XIM が従来にも競合しなかったのと同じです。

      入力方法というか変換エンジン (canna、skk など) は、言語や好みに応じて豊富な選択肢から選べるようになっているべきです。ところが、アプリケーションが直接変換エンジンに接続する方法だと、アプリケーション開発者への負担が大きいため、けっきょく変換エンジンはわずかなアプリケーションでしか利用できないことになってしまいますので。それに、全世界の言語の知識を、個々のアプリケーション開発者が持っていないといけなくなります。そこで、変換エンジンとアプリケーションのあいだにレイヤーを追加するのがよい、ということになります。SCIM、IIIMF、uim、immodule、XIM がこれに相当します。

      親コメント
    • by Anonymous Coward
      これを通して日本語を入力するものは無い?
      • Re:位置づけ (スコア:1, 参考になる)

        by Anonymous Coward on 2004年09月05日 21時06分 (#617556)
        uimとのブリッジがあるって、書いてあるじゃない。

        scimに限らず、ここらへんの位置づけについては、 入力システムの概要 [osdn.jp]というMLの投稿記事があります。御参考までに。
        親コメント
        • Re:位置づけ (スコア:1, 興味深い)

          by Anonymous Coward on 2004年09月06日 13時06分 (#617773)
          上記記事から、uimとscimの関係を読み取ろうとしたんですが、uim開発者の田畑さん自身がscimを認めているのはちょっと意外でした。

          というのは、scimを認めたらuimの必要性はなくなってしまうんじゃないかなと思いまして。

          記事だとuimは2の部分(プリエディット制御)に重点を置いているといいますが、uimは別途cannaやwnnなどの1の部分(変換エンジン)を必要とします。で、cannaやwnnは2の部分も持ってるわけだから、じゃあuimをなくしてscimから直接cannaやwnnに接続したほうがシンプルだね、となりそうです。

          親コメント
        • by Anonymous Coward
          入力システムの概要 [sourceforge.jp]というML
          そんなMLはあるわけがない。
          • by Anonymous Coward
            「 入力システムの概要 [sourceforge.jp]というMLの投稿記事」と書いたのですが。
  • by Anonymous Coward on 2004年09月05日 16時02分 (#617478)
    この手の物が乱立しててややこしくてわけわからない。

    あと、C++ じゃないと駄目なの?
  • by Anonymous Coward on 2004年09月06日 1時36分 (#617648)
    同時打鍵が特徴の、親指シフトでの入力はこれでできるようになるのでしょうか?
    • by Pen2 (18210) on 2004年09月06日 12時26分 (#617760)
      キーボード直接のカナ入力は難しいですが
      ローマ字入力モードの場合は、限定的な同時打鍵は出来る
      KA→か と AK→か のように、逆順もローマ字表に登録します
      ローマ字かな変換のアルゴリズムの制約によります
      母音がAIUEO固定とか Y、M 、N などが固定処理されていると
      できませんが。
      親コメント
      • by Anonymous Coward

        限定的というのは、少々つらいですね。

        一般的な PC のキーボードで親指シフトする場合、同時打鍵に使用する右シフトと左シフトキーには、"変換" "無変換" "空白" のキーのいずれか二つを使うことになると思います。ここで仮に左シフトに "空白" を、右シフトに"変換"を使うことを考えます。 するとキーの "s" を押した場合次のように出力する必要があります。

  • by Anonymous Coward on 2004年09月07日 13時37分 (#618335)
    日本語入力は、もじらにどのLOCALEでも使える様になって嬉しい。kinput2を忘すれ、新しいのに慣れて見ましょう。
typodupeerror

Stay hungry, Stay foolish. -- Steven Paul Jobs

読み込み中...