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

Mozilla プラットフォームで開発してみませんか 36

ストーリー by yoosee

line曰く、"Mozilla は、クロスプラットフォームなインターネットクライアント開発のためのアプリケーションフレームワーク「XULRunner」のプレビュー版を公開した(プレスリリース)。今回公開された XULRunner 1.8.0.1 は Firefox 1.5.0.1 と同じコードがベースとなっており、Mozilla Developer Center からダウンロードできる。

XULRunner は、 Firefox や Thunderbird といったアプリケーションの基盤となっている XUL と XPCOM を用い、リッチクライアントを開発するのに利用できるフレームワーク。レンダリングエンジン Gecko やネットワークライブラリ Necko も同様に利用できる。
(続く)

XUL(XML-based User-interface Language)とは、 GUI を XML で定義する(ウィジェットを XML で指定し、見た目は CSS、動作は JavaScript でそれぞれ書く)もので、 MS の XAML と似ている。 XPCOM(Cross Platform COM)は名前の通り、プラットフォームに依存せずにオブジェクトの操作を提供する。なお IBM との共同開発により、Eclipse での開発もできるようになっているらしい。

すでにウェブオーサリングツール Nvu (スラドの記事)や、 メディアプレイヤー Songbird(同記事)、WengoPhone(Skype に似た IP 電話クライアント)といったプロジェクトがこの技術を利用して開発されている。今後はインストーラや配布のためのフレームワークといった機能拡充が予定されているとのこと。

Firefox/Thunderbird の拡張としてはいろいろなソフトウェアが出ているが、 XULRunner を利用したスタンドアロンなものも今後増えてくるだろうか。個人的には Mozilla as a PlatformFlash も Platform 化など、プラットフォームとして発展していこうとするプロダクトが最近の流れ? などと思ったりしました。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by ruto (17678) on 2006年02月08日 23時06分 (#880053) 日記
    Luxor [sourceforge.net]: XULとPython(やJava)でアプリケーションが作れる。
    XUL2GTK [phppatterns.com]: XULとPHPで書いたコードをPHP-GTKのコードに変換。
    Jazilla [dhs.org]: Javaで書かれたXULエンジン(あまり進んでない?)

    #どれも使ったことないので使ったことある人フォローよろ。
    • by bool (6916) on 2006年02月09日 10時19分 (#880287) ホームページ

      Hans Muller's JavaOne session: Defining Swing GUIs Declaratively [swixml.org]に,SwingのGUIをXMLで書くフレームワークいろいろがレビューされています.死屍累々です.

      親コメント
      • by bool (6916) on 2006年02月09日 10時21分 (#880291) ホームページ

        XUL and Java. It seems obvious to me. [javadesktop.org]という投稿には,こういうXULなどのフレームワークを評価するためのdiciplinesが列挙されていて,参考になります.以下引用します:

        1) Does it support multi-platform applications well? For example, OS X users complain about the poor Mozilla XUL UI.
        2) How easy can you express/produce simple things?
        3) What design quality can you achieve? Is the hard stuff possible?
        4) Does it help you achieve a well-designed UI?
        5) Can everybody in your team work with the solution?
        6) What about the readability of the layout description? Can you understand and edit what your collegue has designed?
        7) What about compile-time safety?
        8) What about tool support: e.g. editor support, code-completion? Can you browse references?
        9) Does your editor integrate with your refactoring tool?
        10) How easy can you find and fix bugs? Can you debug the build process and component configuration?
        11) Does it support your favorite widget toolkit well? For example, can you work with the GlassPane? And does it integrate with Java2D?
        12) Does it support multiple widget toolkits? (Without ending up with the worst of all worlds).
        13) Can you rely on the solution vendor?
        14) How large is the extra download size?
        15) How much does it cost?
        16) Is support available?
        17) Can you change the layout at runtime?
        18) Can users change the layout at runtime?
        親コメント
    • Luxorは昔、卒論でXULの実装をPythonで作ってたときに、ソースコードのレイアウトとかを参考にしました。
      ...実際の使い方はさっぱりわからんかったとです。
      # へたれなんでID
      --
      三日風呂に入らなかったら、あなたはすめるまんです。
      親コメント
    • by Pen2 (18210) on 2006年02月09日 9時30分 (#880260)
      MSの XAMLとか、Macromedia Flex 1.5日本語版や、非xmlの curl言語とか、比較して完成度は?
      親コメント
  • by Anonymous Coward on 2006年02月08日 23時21分 (#880071)
    XMLでGUIの引継ぎ仕事やったことあるんだけど
    それは制御部分までXMLで書くという恐ろしいものだった。

    IFとかメソッド呼び出しとかが全部タグになってんの
    あれのメンテはいま思い出してもおそろしい‥

    # さすがに正体バレるだろうからAC
    # ちなみに○○○の○○○○○○で今も稼動中
  • by Anonymous Coward on 2006年02月09日 3時33分 (#880207)

    Linux ではうまく動くから、という理由だけで他プラットフォームでは全くうまく動かなくなるような変更を何のためらいもなく入れたりとか平気でやってくれるような「プラットフォームに依存せずに」利用できる環境なんて触りたくもないっていう感じ。もちろん nightly とかで突っ込む程度ならいいんですが、release まで壊れたままとか、勘弁してくれって感じです。

    もじら組の連中とかに至っては「NSPR って触っていいの?」とか言うようなのが普通にいるし。

    Mozilla 関係は他に選択肢がなくてしょうがなく使うという事はあっても、積極的に利用したい、協力したいと思う事は全く無い。そう思わせる体制や雰囲気とかから考え直したほうがいいと思う。

    Firebird 関係者とかも同じ様に思ってるんじゃないかな。

    # 実際に壊されて迷惑したので AC

  • by Anonymous Coward on 2006年02月08日 23時27分 (#880078)
    日本語のドキュメントがもっと簡単に見つかるようになれば、
    もうちっとやる気にはなるんだけどだぁ。

    # 誰か知ってる人、ポインタよろ。
    • by Anonymous Coward on 2006年02月09日 1時06分 (#880145)
      最近XULを勉強し始めました。
      Googleさんで一番に出てきた翻訳を読んでいたらなぜかサンプルが実行できない。
      よく見たら2001年の翻訳だそうでトップにはもう更新しないと書いてあって驚いたところです。
      #nsIFileのdelete->removeでした。

      XULは面白いのですがGUIをXMLで書くのはしんどいですね。
      Springとか挙動はFireFoxに放り込むまでわからないですし、なぜ思い通りにいかないかで悩みそうです。
      このへんはJavaのAWTやSwingを手書きするのに似ていると思います。ですのでNetBeansのマチスがXULに対応してくれたらどれだけうれしいかと思いました。

      またFireFox上のXULはセキュリティが厳しくて大変みたいですね。Canvasの画面を保存するためのtoDataURL関数はセキュリティの考慮上リリースから消されてしまったそうでとても残念です。

      JavaScriptは変数のスコープの問題や、弱い片付けでメソッド引数に型が指定できないことなどからあまり大きなプログラムの開発には向いていないと思います。他の言語も使えるようにぜひしてほしいものです。

      でも以上の細かな点をひっくるめても本当に面白いです。
      まだ始めていない人にはぜひお勧めしたいです。
      親コメント
      • by Anonymous Coward on 2006年02月09日 17時49分 (#880566)
        このストーリーは、微妙に的外れなレスが多いですね。

        ツッコミを始める前に、XULRunnerというのは、XULのネームバリューにあやかって付けられた名前ですが、決してXULを使うためだけのものではありません。タレコミにもあるように、FirefoxやThunderbirdのような環境を構築するに当たって、共通する部分を抜き出してある、というのがより正確です。そういう意味では、以前のプロジェクト名"Gecko Runitme Environment (GRE)"の方が、内容としては相応しいかったかもしれません(マーケティング的にはダメダメですが)。

        GREのような剥き出しのライブラリとは違って、XULRunnerはXULだけでほぼ動くようになっています。が、一方で、XULを一行も書かずに、javaやC++で済ます事もできます。

        XULRunnerが提案しているのは、「もしUIが要るならXULにしてみたら?」と言う事に過ぎません。というのも、それが一番得意な分野だから、つまり、レイアウトエンジンGeckoがcssを元にボタンやスクロールバーを配置してくれるから、です。

        > XULは面白いのですがGUIをXMLで書くのはしんどいですね。
        そうですね。ただ、UIはいずれマークアップ言語で書くことになると思います。まあ、APIでも記述できるでしょうが、それよりは楽でしょう。ML同士を比べてみると、XMLは特に劣っているわけではないと思います。控えめに言っても。

        > Spring
        そんな要素は、昨今、どんなリファレンスを見ても載っていません。さすがに古すぎです。

        > またFireFox上のXULはセキュリティが厳しくて大変みたいですね。
        それは、Firefoxの開発者が決めたルールで、XULRunnerで開発する場合は、全く関係ありません。

        > JavaScriptは変数のスコープの問題や、
        > 弱い片付けでメソッド引数に型が指定できないこと
        > などからあまり大きなプログラムの開発には向いて
        > いないと思います。他の言語も使えるようにぜひ
        > してほしいものです。

        使えます。特に、javaはほぼ自在に使えるといっても過言ではないでしょう。単にインタープリタをjavascriptに限っているだけです。

        #モデレートしちゃったのでACで。
        親コメント
        • by Anonymous Coward
          > > XULは面白いのですがGUIをXMLで書くのはしんどいですね。
          > そうですね。ただ、UIはいずれマークアップ言語で書くことになると思います。まあ、APIでも記述できるでしょうが、それよりは楽でしょう。ML同士を比べてみると、XMLは特に劣っているわけではないと思います。控えめに言っても。
          XML以外のMLを使いたいなんて言っていないと思いますが。
          > > NetBeansのマチスがXULに対応してくれたらどれだけうれしいかと思いました。
          というコメントからも、GUIでレイアウトしたいというのがココロだと読み取れます。
          リソースエディタが付属したまともなIDEに金を出したくないという以外の理由でWindowsのリソースファイルを手書きする人はめったにいません。
      • by Anonymous Coward
        おすすめ度が高いわけではないが、
        googleで見つかるXULチュートリアルが古いという話に関しては、
        http://www.mozilla.gr.jp/jt/xul/progress.html
        の作業途中のものの方がまだ新しい。
        #こっちの通りやれば今のバージョンで全部動くなんていう保証は一切しないが。
    • by Anonymous Coward on 2006年02月08日 23時34分 (#880081)
      英語のサイトみても、どれが最新の情報なのかよくわからなかったりします。XUL自体の仕様もがんがん変わる、とか書いてあるし。

      今現在、リリースされたXULRunnerに対応している一番信頼できるドキュメント(日本語でなくても可)ってどれなんですかね?
      親コメント
  • by 2nd.cc (28719) on 2006年02月09日 13時36分 (#880408) ホームページ 日記
    魅力を感じないなぁ
    一応クロスプラットフォームを目指していた
    Javaと比べて、何を目指すのだろう。
    • Re:特に (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2006年02月09日 20時21分 (#880642)
      Firefox の UI が Java だったら間違いなく流行らなかったと思います。
      親コメント
    • by Anonymous Coward
      ネイティブじゃないだろうか?
      あともっとしっかりしたGUIとか
  • by Anonymous Coward on 2006年02月08日 22時41分 (#880024)
    コアAPIがFirefoxと統合されればうまくいきそうなんだけど
  • by Anonymous Coward on 2006年02月08日 23時28分 (#880079)
    FirefoxとThunderbirdの共通部分がひとつのXULRunnerに共有される様になるといいな。
    GNOMEをインストールするのにFirefoxやMozillaを入れなくてもXULRunnerだけを入れれば済むようになるといいな。
typodupeerror

クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人

読み込み中...