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

GNOME用アプリケーションはGnomeFiles.org 33

ストーリー by Oliver
足型のコレクション 部門より

mumumu 曰く、 "GNOME Projectサーバに侵入された形跡が見つかって以来、GNOME用アプリを配布する中心的な場所が存在しない状態になっていた。その穴を埋めるべく、OSNews LLCが、BeOS用アプリの配布場所として知られているBeBitsをモデルに、GnomeFiles.orgを構築したとアナウンスしている。ここではGNOME用アプリ、もしくはGTK+(とそのbindingも含む)で作られたアプリの登録が可能になっており、サイトオープンから一週間で、150以上のアプリが登録され、3800件を超えるダウンロードがあったという。また、オープン(6/16)から1~3週間の間に、ユーザー登録を行い、一つ以上のアプリを登録した開発者一人に対し、「自分のソフトウェアを広告できる権利」などの特典が与えられることになっている。我こそはと思うGNOMEアプリ開発者は今すぐ登録してみてはいかが。"

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

    by furyo (10699) on 2004年06月25日 8時37分 (#576621)
    日本人が作っているアプリケーションだと風博士 [gnomefiles.org]が登録されています.
    未踏プロジェクトにも採用 [ipa.go.jp]され,これからが(も)楽しみなブラウザです.
  • by Anonymous Coward on 2004年06月25日 12時35分 (#576785)
    GNOMEにせよKDEにせよアプリ開発者が日本にはあまりいないから?
    • desktopで日本語を使う環境が安定してないですから、
      開発しようという気もうせるのでは。
      アップグレードや、アップデートするたびに、日本語入力が
      動かなくなるのではと心配しないといけない現状ですからね。
      --
      romfffromのコメント設定
      AC-2、プラスモデ+3、閾値0、スコアを表示しない(推奨)、高い評価のコメントを親にする
      親コメント
      • KDE方面の現状は知らないですが、少なくともGNOME(GTKアプリ)なら、GTK+2を使ってるかぎり、日本語入力のことはまったく意識しなくても大丈夫です。少なくとも私は全く気にしてません。独自ウィジェットを作るとなるとちょっとは考慮しないといけないですが。

        肉好き作者
        • 90082 Input Methods need to receive any key event
          111438 Widget should be recieve key event before mnemonics and sccelerators

          前にも書いたけど、このあたりって直ったんでしょうか?

          直っていないとしたら、CTRL+Nで新しいウィンドウが開くとかCTRL+Fで検索ダイアログが出てくるとかなどの現象のため漢字入力ができず、少なくとも私にとっては、GNOMEでの日本語入力は大丈夫じゃありません。
      • > desktopで日本語を使う環境が安定してないですから、
        > 開発しようという気もうせるのでは。

        だったら、そもそもデスクトップマシンにLinuxや*BSDを使う気がしないような気がしますが。というか実際にデスクトップマシンにしてる人が少ないのか。

        日本語(だけじゃないけど)入力環境の改善に関してはscim [freedesktop.org]がuimやm17n-libに対応したり、immodule for Qtがfreedesktop.org [freedesktop.org]でホストされたり、あと
  • by Anonymous Coward on 2004年06月25日 12時56分 (#576798)
    どうすればよいのでしょうね? GnomeにしろKDEにしろ。
    • 1.開発HowToが書かれた日本語の書籍は少ない・・・気がする。

      2.VBみたいに簡単にGUI作れるの?
      VC++未満のWin32API叩くような感じな気がするけど・・・
      そういえば、Kylixとか聞いたけど使えるようにするのは簡単?

      3.KDEとGnome、gtkとかqtって何?
      そもそも違っても別のLinux環境でも動くの?

      4.理想は言語内ですべて済めばいいけど、そうはいかないし。
      さて、日本語のAPIドキュメントってあるのか?
      MSDNレベルの整理されたドキュメントは欲しいなぁ。
      開発環境に統合されてれば最高!

      5.IME(FEP)の制御って簡単に出来るかな?
      まさかFEP毎に別のAPIをコントロールがフォーカス取得時に
      手動で送信とかいう冗談みたいな事はないよね?

      6.文字コード意識しないといけないの面倒。
      EUCかUnicodeかなんでもいいから統一してくれ。

      7.このプログラムは将来的にも一応動くの?
      今作ったプログラム、とりあえず5年は動くかなぁ?
      ランタイムのバージョンが新しくなって動かなくなって、
      ヘルプで時間取られるの嫌だしなぁ。

      8.インストーラー簡単に作れないかなぁ?
      rpmやdebを自動的に構築。
      必要ライブラリもインストールor警告出すようにとか。
      スタートメニュー(というかランチャ?)に登録もしてくれよ~

      9.このショートカットキーの組み合わせ、
      この環境だとOKだけど、別の環境でも使えるんだろうか?

      10.そもそも、日本語文字列の処理うまくいくのかな?
      左から何文字目とかやったら、
      左から何バイトに解釈されてへんな所で切れないだろうなぁ?

      とか色々書いてみましたが現状どうなっているやら・・・
      あと、言語と環境がごっちゃになっててすいません。
      親コメント
      • 一応KDevelopでKDE/Qtのアプリを開発してるのでツッコミ。

        > 1.開発HowToが書かれた日本語の書籍は少ない・・・気がする。

        あることはあるのですが、古いものばかりですね。
        KDE/Qtは2.xから大きくは変わってないので、それなりに使えますが。

        > 2.VBみたいに簡単にGUI作れるの?
        > VC++未満のWin32API叩くような感じな気がするけど・・・

        Qtに関して言えば、Qt Designer [trolltech.com]があるので楽です。

        > 4.理想は言語内ですべて済めばいいけど、そうはいかないし。
        > さて、日本語のAPIドキュメントってあるのか?
        > MSDNレベルの整理されたドキュメントは欲しいなぁ。
        > 開発環境に統合されてれば最高!

        英語なら充実してるのですが…orz
        開発環境との統合については、一応KDevelopからリファレンスが見れたり、
        Qtのクラス名を選択して検索などが出来ます(KDEのクラス検索はうまくいかなかった)。

        > 6.文字コード意識しないといけないの面倒。
        > EUCかUnicodeかなんでもいいから統一してくれ。

        Qtの場合内部がUnicodeなので、コードに直接EUCで書く場合は変換する必要があるくらいかな(QString::fromLocal8Bit())。
        ファイル入出力はデフォルトで設定されているロケールを利用するのでたぶんOK。

        > 7.このプログラムは将来的にも一応動くの?
        > 今作ったプログラム、とりあえず5年は動くかなぁ?
        > ランタイムのバージョンが新しくなって動かなくなって、
        > ヘルプで時間取られるの嫌だしなぁ。

        同じメジャーバージョンならバイナリ互換性あったような気がするけど細かい所は忘れた。(3.1.xと3.2.xって互換性あったっけ)
        まあ、static linkすれば大丈夫かと。
        # ライセンスの話はここでは略。

        > 8.インストーラー簡単に作れないかなぁ?
        > rpmやdebを自動的に構築。

        KDevelopには*.spec作成用のダイアログがあります。
        動作が怪しいので使ってないですが(^^;)

        > 必要ライブラリもインストールor警告出すようにとか。

        rpmの機能ですね。必要ライブラリの依存関係はrpm4から自動チェックしてくれたはず。

        > スタートメニュー(というかランチャ?)に登録もしてくれよ~

        KDevelopで新規にプロジェクトを作成するとメニューへ登録するためのファイルも作ってくれるはず。

        > 10.そもそも、日本語文字列の処理うまくいくのかな?
        > 左から何文字目とかやったら、
        > 左から何バイトに解釈されてへんな所で切れないだろうなぁ?

        そういう酷いのはまずないです。
        Unicode ←→ "Shift_JIS"のマッピングとか、フォント関連とか、地雷源は大量にありますが…。
        親コメント
      • by Anonymous Coward on 2004年06月25日 16時38分 (#576920)
        嘘書いてたら訂正が入ることを期待して、書き殴ってみました。

        > 1.開発HowToが書かれた日本語の書籍は少ない・・・気がする。

        VB 等に比べるまでもなく、実際に少ないと思います。
        Web のリファレンス/チュートリアルでは不満な人には、厳しいかも知れません。

        > 2.VBみたいに簡単にGUI作れるの?
        > VC++未満のWin32API叩くような感じな気がするけど・・・
        > そういえば、Kylixとか聞いたけど使えるようにするのは簡単?

        kylix を使えるようにするのは、単にインストールするだけなので簡単でしょう。

        フリーの UI ビルダも、 GTK 向けの glade があります。
        Qt 向けのは知らないので、詳しい人のフォローを希望。

        > 3.KDEとGnome、gtkとかqtって何?
        > そもそも違っても別のLinux環境でも動くの?

        KDE と gnome は、デスクトップ環境の名前です。

        gtk と Qt は、 GUI を提供するライブラリの名前です。

        使うライブラリさえ揃えれば、ディストリビューションが異なっても動くでしょう。
        ライブラリを揃えさせるのが面倒なら、 statically linked なバイナリにすれば、何も考えずに動かせるでしょう。

        > 4.理想は言語内ですべて済めばいいけど、そうはいかないし。
        > さて、日本語のAPIドキュメントってあるのか?
        > MSDNレベルの整理されたドキュメントは欲しいなぁ。
        > 開発環境に統合されてれば最高!

        MSDN のように一枚岩のドキュメントはありません。

        各ライブラリの API リファレンスも、新しいものは日本語に翻訳されていなかったりします。

        > 5.IME(FEP)の制御って簡単に出来るかな?

        Input Method 周りは鬼門です。
        最近の gtk immodule なら、だいぶ楽になってきてはいるようですが、詳しいことは分かりません。
        フォロー希望。

        > まさかFEP毎に別のAPIをコントロールがフォーカス取得時に
        > 手動で送信とかいう冗談みたいな事はないよね?

        日本語としてパースできませんでした。

        > 6.文字コード意識しないといけないの面倒。
        > EUCかUnicodeかなんでもいいから統一してくれ。

        プログラム内部コードは、 4 byte の wchar_t で統一されています。

        最近では、インストール直後からロケールが適切に設定されるので、外部コードが EUC であっても UTF-8 であっても、 (多分) 悩む必要はありません。

        > 7.このプログラムは将来的にも一応動くの?
        > 今作ったプログラム、とりあえず5年は動くかなぁ?
        > ランタイムのバージョンが新しくなって動かなくなって、
        > ヘルプで時間取られるの嫌だしなぁ。

        難しい問題ですが、 statically linked なバイナリなら 5 年くらいは動くのではないかと。
        # 5 年後に X が無くなっていると無理ですが…。

        この辺は、 VB でも同じような物じゃないかな。

        > 8.インストーラー簡単に作れないかなぁ?
        > rpmやdebを自動的に構築。
        > 必要ライブラリもインストールor警告出すようにとか。
        > スタートメニュー(というかランチャ?)に登録もしてくれよ~

        一定のルールに従ったソースコードなら、 deb はコマンド一発で作れて、ライブラリの依存関係も勝手に計算されます。
        rpm は良く知りませんが、似たような仕組みはあるのではないかと。

        メニューへの登録も、いくつかの簡単なテキストファイルを用意するだけです。

        > 9.このショートカットキーの組み合わせ、
        > この環境だとOKだけど、別の環境でも使えるんだろうか?

        微妙です。この辺りは、 95 以降の Windows の方が統一されているでしょう。
        ある程度安全に使える組み合わせはあると思うのですが、詳しいことは分かりません。

        > 10.そもそも、日本語文字列の処理うまくいくのかな?
        > 左から何文字目とかやったら、
        > 左から何バイトに解釈されてへんな所で切れないだろうなぁ?

        最近は wchar_t があるので、日本語を扱う程度なら、意図的に変なことをしない限りは大丈夫です。
        親コメント
        • by Anonymous Coward on 2004年06月25日 18時39分 (#576989)
          >> 1.開発HowToが書かれた日本語の書籍は少ない・・・気がする。
          >
          > VB 等に比べるまでもなく、実際に少ないと思います。
          > Web のリファレンス/チュートリアルでは不満な人には、厳しいかも知れません。

          手元にKDEの本が3冊、Qtの本が1冊あります。入門用には足りたけどやっぱ少ない。

          >> 2.VBみたいに簡単にGUI作れるの?
          >> VC++未満のWin32API叩くような感じな気がするけど・・・
          >> そういえば、Kylixとか聞いたけど使えるようにするのは簡単?

          KDEやQtが想定してる範囲内ならMFCより楽。
          それより下の層を触るときは、X11やシステムコールはWin32APIよりプリミティブなのでどのあたりまでいじりたいかによる。

          >> 4.理想は言語内ですべて済めばいいけど、そうはいかないし。
          >> さて、日本語のAPIドキュメントってあるのか?
          >> MSDNレベルの整理されたドキュメントは欲しいなぁ。
          >> 開発環境に統合されてれば最高!
          >
          > MSDN のように一枚岩のドキュメントはありません。
          >
          > 各ライブラリの API リファレンスも、新しいものは日本語に翻訳されていなかったりします。

          ドキュメントの質はMSDNに及ばないですね。細かい挙動追いたいときはソースある分楽なんですが、どこまで仕様でどこまでが現在の実装なのかはわかりにくいです。

          >> 7.このプログラムは将来的にも一応動くの?
          >> 今作ったプログラム、とりあえず5年は動くかなぁ?
          >> ランタイムのバージョンが新しくなって動かなくなって、
          >> ヘルプで時間取られるの嫌だしなぁ。
          >
          > 難しい問題ですが、 statically linked なバイナリなら 5 年くらいは動くのではないかと。
          > # 5 年後に X が無くなっていると無理ですが…。

          すくなくともMacOSXとXみたいな感じではXは残るだろうから心配要らないと思います。

          >> 9.このショートカットキーの組み合わせ、
          >> この環境だとOKだけど、別の環境でも使えるんだろうか?
          >
          > 微妙です。この辺りは、 95 以降の Windows の方が統一されているでしょう。
          > ある程度安全に使える組み合わせはあると思うのですが、詳しいことは分かりません。

          デスクトップ環境ごとに規約はありますが、カスタマイズ可能にしとくべきなんでしょうね。
          親コメント
          • >>> 今作ったプログラム、とりあえず5年は動くかなぁ?
            >> 難しい問題ですが、 statically linked なバイナリなら 5 年くらいは動くのではないかと。
            >> # 5 年後に X が無くなっていると無理ですが…。
            >すくなくともMacOSXとXみたいな感じではXは残るだろうから心配要らないと思います。

            現状を知らないんですが、
            Staticにしたら、洒落にならないサイズ…になったりはしないものですか?

            Delphiとかでも(DelphiライブラリをStaticLinkした)実行ファイルは数百kbで、
            更にWinだと本体据付なGUI足回りの多くの部分も、GNOME/KDEだと「StaticLink」
            しないとならんわけですよね。

            #いくらディスクが安くなったとはいえ、やっぱり大きい実行ファイルが山のように存在してると気が滅入るのでG7
            ##そのせい「も」あって、近年はめっきりScript言語野郎してます。小ささとメンテ性を考えるとScriptが一番かも。
            親コメント
            • サイズは爆発的に増えますね。
              でも実際はGnomeにしろKDEにしろフリーソフトの99%ぐらいはソースで配布にするかパッケージで配布して依存ライブラリはパッケージングシステムに任せるかで問題にはなってない気がします。
              • >でも実際はGnomeにしろKDEにしろフリーソフトの99%ぐらいはソースで配布にするか

                ソースからmakeすることの、初心者(??)に対する敷居を、下げないとアレですね。

                …とはいえ、自分で考えてOptionいじる必要がある場合でもなけりゃ、
                makeそのものが難しいっていう感覚はほぼゼロですね。
                「インストーラー」がconfigure;makeをすればそれでいい、のかな…

                >パッケージで配布して依存ライブラリはパッケージングシステムに任せるかで問題にはなってない気がします。

                100個のアプリが、100個の「バージョン違いの」ライブラリを要求したら、
                結構悲惨なことになりそうですね(^^;

                ところで、やっぱりライブラリ間の依存関係ってのは、
                ガベージコレクションみたいに
                参照カウント法とかマーク&スイープ法とかで
                「不要」になったことを判断して自動アンインストールする(してくれる)ものなん…ですよね??

                #メモリ管理(GC)と比較して考えると、「ライブラリを置くPathはmake時に確定すべきだ」
                #というUnix的(?)発想は、前近代的だなと思えてならないのでG7
                #名前に束縛されることで、複数の共存がやりにくくなるじゃん。
                #malloc()の出力はアドレスを問わないのが味噌なんだよね。名前空間的にも物理空間的にも"Location"の縛りが無い。
                親コメント
            • 576920 の AC です。

              > 現状を知らないんですが、
              > Staticにしたら、洒落にならないサイズ…になったりはしないものですか?

              なりますね。

              Windows 環境での開発には詳しくないのですが、 Windows アプリケーションを配布する際には、 DLL の非互換性を嫌って、実行ファイルと同じディレクトリに DLL を置くのが普通になっていると聞きました。 DLL Hell と呼ばれてるとか何とか。
              # 昔は、アプリケーション毎に、違うバージョンの MFC42.DLL を持ってたりしましたよね。最近は違うのかな?

              こんなこ
              • by kei100 (5854) on 2004年06月27日 18時44分 (#577784)
                システムフォルダにあるMFC42.dllが、
                インストーラーによっては、古いバージョンのMFC42.dllで
                新しい物を上書きされてしまうのが問題だったと思ってます。

                どちらかといえばインストーラの問題なので、
                WindowsやMFC42.dll側の問題とは違う気もします。

                そこらへん、Linuxだとインストールするのに、
                依存関係のチェックがあるものが多いので発生しないのかも。
                親コメント
          • 参考になりました。
            現状書籍は入門用はそこそこ出ているのですね。
            今度大型の書店にでも行って探してみます。

            KDEやQtが想定している範囲内はMFCより楽という事なので、
            難易度としては、VB以上VC未満みたいな状態かな?
            # VBも凝った事をしようとした瞬間複雑化するので。

            ここを見ればOKみたいなAPIドキュメントとかが、
            現状少ないみたいなのがこれから作るとしたら怖い点ですかね。
            困ったときに見るリファレンスが難解だとか、
            必要なドキュメントが見つからないといった状態になると挫折するかも。
            親コメント
        • >> 5.IME(FEP)の制御って簡単に出来るかな?
          > Input Method 周りは鬼門です。
          > 最近の gtk immodule なら、だいぶ楽になってきてはいるようですが、詳しいことは分かりません。
          > フォロー希望。

          >> まさかFEP毎に別のAPIをコントロールがフォーカス取得時に
          >> 手動で送信とかいう冗談みたいな事はないよね?
          > 日本語としてパースできませんでした。

          やりたいこととしては、名前と名前のカナを入力する欄があるとしたら、
          自動的に日本語入力がONになったり、カナ入力モードになったりという、
          ユーザーに対しての入力支援ですね。
          Win32 APIなら統一されたAPI [microsoft.com]を使用することで、
          ATOKなのかMS-IMEなのか、そもそも日本語のIMEなのかを意識しないで変更できます。

          >この辺は、 VB でも同じような物じゃないかな。
          たしかに、VB Runtimeが無くて動かないって場合もありますね。
          一応Win95時代のアプリも一応動く実績があるので・・・
          LinuxのGUIアプリってどうなのかな?と思ったり。

          >メニューへの登録も、いくつかの簡単なテキストファイルを用意するだけです。
          これは、環境非依存・・・
          例えば~/.kde~~が/tmp/startmenu/のように変更されていてもOKなのでしょうか?
          こうすると、ユーザーが好きな場所に登録が出来ない気もします。

          まぁ、ここらへんはLinuxで動く対話型GUIなインストーラーが、
          KDEやらGnomeが標準で用意してくれたら良いのかもしれませんが。

          <おふとぴ>
          # 傍から見てると、LinuxのGUIアプリってシェアを
          # 身内で食い合ってる様に見えるのは気のせいなんだろうか?
          </おふとぴ>
          親コメント
        • > フリーの UI ビルダも、 GTK 向けの glade があります。

          glade休眠中…お願い復活して。

          > 最近は wchar_t があるので、日本語を扱う程度なら、意図的に変なことをしない限りは大丈夫です。

          cygwinでは16bitなのが泣ける (;_;)
      • > 1.開発HowToが書かれた日本語の書籍は少ない・・・気がする。

        最近はけっこう増えてきた・・・と思う。
    • デベロッパーがらみのストーリーとその他のストーリー(CCCDネタとか)の差を見るとそもそも開発者そのものが少ないと思うのです。
      今まで見聞きしている限りでは、なんかフツーvs開発者の比率って1000:1程度の様な気が・・・・
      --
      -----------------
      #そんなワタシはOS/2ユーザー:-)
      親コメント
      • なんかフツーvs開発者の比率って1000:1程度の様な気が・・・・
        そうなんでしょうか?この記事 [itmedia.co.jp]によれば、
        ソフトウェアのプログラミングについては、88%のユーザーが行っていると回答し、そのうち46%のユーザーが仕事・趣味両方でプログラミングを行っている
        となってるんですけどねぇ。

        親コメント
        • by amura (15484) on 2004年06月25日 19時05分 (#577000) 日記
          仕事・趣味でプログラムを作っているけど、GUIがいるプログラムは作らないという人が多い気がします。高機能なツールキットで楽になったとはいえ、やっぱり GUI は面倒くさいです。
          さらに、公開するとなれば、他人が使うことを考えなければならないわけです。いろいろな人/場面を想定する必要があって、かなり気力がいると思います。

          # 最近仕事?で作っているプログラムは、テキストフィルタ的なものばかり。
          # モデル化データを作って、シミュレータに突っ込んで、出力切り出してグラフに加工...
          # 拡張に拡張を重ねたせいで、人には見せられないプログラムに。
          --
          なんちゃってプログラマ?
          親コメント
          • by G7 (3009) on 2004年06月25日 20時53分 (#577055)
            >GUIがいるプログラムは作らない

            アプリもいいんだけど、(GUIな)ライブラリ…典型的なのはWidget…も
            みんな沢山作って欲しいなあ。

            と、Delphi出身者な俺は思うのでした。
            フリーかつソース公開(The OSI OpenSouceかどうかはさておき)な
            Widget(Delphi弁だとComponent)が結構沢山あるんですよね。あれが気持ちよかった。

            で、APIというかフレームワークというか…が秀逸ならば、
            GNOMEの一番偉い人によれば、
            「2000行で気楽にWidget作って公開!なんてのがさくさく出来るっしょ」
            ってことだそうです。
            プチアプリとしてのWidgetってのは、結構いいもんですよ。いろんな意味で。

            で、その次の段階として、
            そういったフリーのWidgetをかき集めてアプリらしきものを
            とりあえず手早くでっち上げられる環境が有れば、
            めでたしめでたし(=「アプリ」の生産性がshなみになる)です。

            ん。たぶん、Widget作者とアプリ作者が、
            (あくまで結果としてだけど)分離されるといいんだよね。

            …ご健闘をお祈りします。
            親コメント
          • UIの設計が苦手な人って多いのかな。GNOMEでもファイルセレクタとかファイルマネージャを作り直したときに「何でこんなUIになるの?」という感じで評判が悪かったりしますし。
            • GUIというとどうしてもWindowsっぽいのをイメージしちゃうのが問題だと思う。
              似たものとなるとどうしても前のと比べちゃうし。

              GTK+1.xについてたファイルマネージャーっぽいやつはよかったんだよな。
              TAB補完に慣れた指で違和感なく使えるよう作ってあって。
              ああいうCUI文化をうまく継承したGUIなんかがもっと増えたら
              おもしろいんだけど。>PC-UNIXのGUI
        • 88%のうち、CGIのパラメータセットしただけで自作と言い張る人 [sakusenki.com]が86%ぐらいいるのではないかと・・・
typodupeerror

開いた括弧は必ず閉じる -- あるプログラマー

読み込み中...