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

Mozillaアプリ開発のバイブル登場 70

ストーリー by Oliver
恐竜を意のままに 部門より

programmer 曰く、 "O'reilly本 "Creating Applications with Mozilla"がmozdev.orgの1プロジェクトとして公開されとります(OPLで公開されている全文)。
英語は読めんでもサンプルコードはわかるので、いくつか試してみたけどXULっておもろいわ。まさかXMLでGUIが組めるとはねー。うーん、マルチプラットフォームなGUI探すより、マルチプラットフォームであるMozillaでアプリ組んだほうがええかも。"

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

    by tix (7637) on 2002年12月05日 17時34分 (#212617) ホームページ
    ぼくは outsider reflex [sakura.ne.jp] を読んで XUL に興味を持っています。今抱えているいろいろが一段落したら勉強したいのですが。
    --
    鵜呑みにしてみる?
    • GRE! (スコア:2, 参考になる)

      by Average (3404) on 2002年12月05日 18時32分 (#212635) 日記
      新もじら瓦版 [mozilla.gr.jp]に乗っていたニュースで、xulアプリをモジラ抜きで直接使えるようにするプロジェクトが進行中だそうですね。

      これとJavaScript(今はECMAスクリプトってんでしょうか?)で出来ないところはJavaも使えるよーん、という話になれば、夢のマルチプラットホーム基盤になりますねー。

      コレがOS2にもあれば当分遊べるなー。
      --
      -----------------
      #そんなワタシはOS/2ユーザー:-)
      親コメント
      • Re:GRE! (スコア:1, 参考になる)

        by Anonymous Coward on 2002年12月05日 20時18分 (#212684)
        今の Mozilla でも XPCom (XPConnect) 経由で Java だろうが C++ だろうが、 好きな言語と対話できますし、 実際 C++ とは頻繁に対話しています(つまり mozilla 本体のコードですな)。
        親コメント
  • XUL (スコア:1, 参考になる)

    by Anonymous Coward on 2002年12月05日 17時29分 (#212614)
    XUL で UI が組めることを驚いているみたいですが、
    実際のところ、たとえば HTML + CSS + CGI でもそこそこの
    UI は作れます。
    HTML が XML になって、CGI が JavaScript になっただけですね。

    しかしながら、JavaScript 経由で XPCom のコンポーネントが
    叩けたりするし、DOM 使ってページそのものをダイナミックに
    書き換えられたりするので、なかなか面白いです。

    XUL を使った時計とかは、だいぶ前から作ってる人が居ましたね。
    • Re:XUL (スコア:3, 参考になる)

      by AtmarkZero (7164) on 2002年12月05日 18時50分 (#212646) ホームページ

      私の勘違いでなければ,すでにデスクトップ環境みたいなもの [oeone.com]もできているようですね・・・

      # 実はXULってスゴい?

      親コメント
      • by Anonymous Coward
        XULがすごいっていうよりは、XPCOMに基づくオブジェクトテクノロジにDOMやXMLベースの技術をマップしていることに価値があると思います。XPCOMの重要性を理解している人って意外と少なそうですね。
    • by Mad Kucky (1893) on 2002年12月05日 17時43分 (#212621) ホームページ
      いや、実際、JavaScriptにはまだまだ可能性が残されてるよ。
      まだまだ使い尽くされてはいない。

      ……ただし、早いところ規格が統一されれば、の話(^^; 使わないのにはそれなりの理由があるのは知ってるし、オイラも普段はサーバサイド命の人間ぢゃき(苦笑
      ……JavaScriptエンジン、外付けにならねーかなぁ……って、ムリか。あれだけべったりくっついてちゃあなぁ……。
      --
      _ to boldly go where no man has gone before!
      親コメント
      • by Anonymous Coward on 2002年12月05日 17時57分 (#212627)
        ……JavaScriptエンジン、外付けにならねーかなぁ……って、ムリか。あれだけべったりくっついてちゃあなぁ……。


        んにゃ、mozilla.org の SpiderMonkey [mozilla.org] とか Rhino [mozilla.org] とか
        頑張れば使えるっす。

        Rhino については WEB PRESS Vol.9 [gihyo.co.jp] の記事が参考になるかと。

        あぁそうだ。Rhino は他の製品にも利用されてます。
        - Tivoli Distributed Monitoring [tivoli.com]
        - How are people using Rhino? [mozilla.org]
        親コメント
        • SpiderMonkeyは別にがんばらなくてもつかえるす
          mozillaソースの(トップでなく)jsディレクトリからmakeするだけ。

          コマンドラインからスクリプトを読んで、JavaScriptエンジンjs3250.dll(windows版の場合)を呼ぶexeができる。

          JavaScriptは言語仕様としては
          ・一通りの制御構造
          ・文字列・正規表現
          ・オブジェクト
          があって、一般的なスクリプト言語としては必要十分だと思うし、
          mozillaの実装だとxmlとかDOMと
          • XULをmozillaの上で動かす、ってんじゃなくて、単にスクリプト言語として(perl/ruby/pythonのように)使って必要に応じてコンポーネントを呼ぶ、って使い方もアリだと思うんだが、そーいうの聞かないね。

            MozillaではDOMにオブジェクトをマップするために、XPCOMを使って実装しています。MozillaのランタイムはXPCOMのランタイムシステムだと言っても過言ではない

        • 村脇さんの http://www.felix.jp/~yugo/js/rhino/index.html を
          はじめ、google で検索すると結構出てきますね。

          Batik にも Rhinoが入っているんですね。
      • by ikemo (901) on 2002年12月05日 22時30分 (#212765)
        JavaScriptはECMAScript [www.ecma.ch]という名前で標準化されてますが…。

        個人的にはJavaScript 2.0 [mozilla.org]が欲しいです。
        グローバル変数と関数で書くのはもうやめたい(T_T)
        親コメント
        • by Mad Kucky (1893) on 2002年12月06日 0時13分 (#212826) ホームページ
          確かにそのとおり

          でも今は、同じCSSが同じ表示にはならない。
          同じスクリプトで同じ(期待した)動作をしてくれない
          同じ名前のオブジェクトが同じプロパティとメソッドをを持っていない 。
          もっと厄介なことに同じ名前のプロパティ/メソッドで違う動作をする(^^;

          誰が悪いと犯人探しをするのは簡単だけど [cruel.org]、今そこにある現実も直視しなければならない。とっても不本意なことではあるけど、ね(T_T)
          --
          _ to boldly go where no man has gone before!
          親コメント
      • by Anonymous Coward
        外付けってどういう意味?
  • by Anonymous Coward on 2002年12月05日 17時45分 (#212622)
    mozdev.org に置いてあるゲーム [mozdev.org]なんかけっこう驚いたり。
    まぁそれに限らず mozdev.org 眺めていると楽しい。
    • でもこのゲームやってて気づいたんだけど、随分とレスポンス悪いです。MozteroidsとかPagmanとか。
      # 私のところだけかもしれませんけど。

      たんなるユーザーインターフェースとしてXULを使うのならば全然問題なさそうだけど、こうやってグラフィック表示
      • by nobuhiro (5244) on 2002年12月05日 18時44分 (#212644) ホームページ
        XUL がマッチしそうなアプリケーションって何かあるかな。

        UI とタイトに結び付いたものが必要な場合、ネイティブのライブラリに比べてパフォーマンスが上がらないし、サーバーとインタラクションが必要な場合、フォームで事足りる。インタラクションを減らす目的なら JavaScript で十分事足りる。

        フォーム+JavaScript より高度で、ネイティブライブラリを使うまでもない用途、となると凄く狭い領域というか、それこそブラウザの UI 設計だけじゃなかろうか、と少し悲観的な私でございます。

        --
        親コメント
        • by Average (3404) on 2002年12月05日 19時24分 (#212662) 日記
          自分はファイルマネージャなんて凄く面白そうな気がします。
          サイドバーにファイル、Webページ、等が登録されていて、メインのペインにWebファイルやローカルファイルが見れてファイルをクリックしたりすると、画像(Gekkoで表示)やhtml(gekkoで表示)、アプリ(ヘルパーアプリとして登録)が動いて、ドラッグアンドドロップでWebページへのアップロードとか、ファイルの整理が出来ちゃったりなんかしちゃったり、とか・・・。機能が足りなきゃローカルなWebサーバーで補助。
          駄目っすか<駄目そうな気がする。
          --
          -----------------
          #そんなワタシはOS/2ユーザー:-)
          親コメント
          • by Anonymous Coward on 2002年12月05日 19時36分 (#212667)
            mozdevには沢山プロジェクト [mozdev.org]があって、例えば「Tools」->「TranZilla」 [mozdev.org]なんかはFTPクライアントですがファイルマネージャーとしても使えそうな感じ。

            他にもオフィスとかCVSのフロントエンドとかあるようです。
            # XULプログラミングって楽しそうだなぁ。
            親コメント
            • 実際のプログラミングの殆どはXULにマップするXPCOMオブジェクトの実装じゃないかと思うんだよな。XULはGUIのデザインでしかない。
              • XULはGUIデザインでしかないとまではオレには言い切れないな。
                まぁ確かにかなりの部分は XPCOMに押し込められてはいるけど
                XUL(XML+CSS+JS)の JS による scriptable な点にも利点がある
                訳だし。
              • JavaScriptはXULの範囲外。DOMオブジェクトに対するJavaScriptによる操作です。
          • ファイルマネージャってブラウザのサブセットでは、という突っ込みは無し?

            WWW ブラウザは、登場当初からファイルマネージャの類をネットワークワイドに拡張したものだ、と言う認識があります。OS と統合される、ってのはそこから来てる話なわけですし。

            つまり、ファイルマネージャを作ると言うのは、ブラウザの UI 設計への適用と同じ事ではなかろうかと思うのです。

            --
            親コメント
            • WWWブラウザはその名が表しているようにブラウズに特化している
              ものなのでファイルのマネージメントの機能は殆どないですよね。
              ファイルマネージャのうち、ファイル・ディレクトリブラウズ
              だけを抜き出してネットワ
              • なんだっけなー、すごーく初期にfjで誰かがWWW vs WWFSみたいな話をしてたのを思い出した気が。各種ブラウザでローカルフォルダを開くとファイルマネージャっぽく振舞うところや、WebDAVなんかの流れを見てると何か、大きなループが一回転、という印象なんですが、これは単に私が頓珍漢な見方をしているだけかも知れない。
                親コメント
              • 歴史は繰り返すのではない、韻をふむのだ、という事でしょうか。
                似たような韻をふむよーなぶつとして
                ・xmlとLISPのS式
                ・インタプリタの興隆
                ・言語の低レベルから高レベルへの変化
                とかありそーな気が。
                タトってる?
                --
                -----------------
                #そんなワタシはOS/2ユーザー:-)
                親コメント
        • by ikemo (901) on 2002年12月05日 23時44分 (#212808)
          普及度とか標準というのはとりあえず無視して…

          「簡単」というのでは駄目でしょうか?
          Form+JavaScriptだけでも多くのことは可能ですが、
          例えば、サブメニューを出そうとすると
          ごちゃごちゃコードを書かないといけなかったような。

          # エディタが何とかしてくれるからいいという話もあるけど。
          親コメント
        • フォーム+JavaScript より高度で、ネイティブライブラリを使うまでもない用途、となると凄く狭い領域というか、それこそブラウザの UI 設計だけじゃなかろうか、と少し悲観的な私でございます。

          どちらかというと、ウェブサイト自体を旧来のアプリケーション的なものにできる、という利点があるというのが私見です。HTTP 経由とかの認証機構がないという問題もありますが。それができれば、.Net と近いものになるのではないでしょうかね

          • Re:なにが出来るかって (スコア:1, すばらしい洞察)

            by Anonymous Coward on 2002年12月06日 0時40分 (#212846)
            XUL が絶対に勝てないのは、速度的なパフォーマンスでしょうね。その代わりに、クロスプラットフォームなサービスを提供できると。Linux の .Net 互換なフレームワークは遅いらしいので、それには勝てるかも知れませんが。
            誰かがXULプログラミングなんて書いたせいで、勘違いさんが多発してるようですが、XULで記述できる範囲はあくまでGUIの部品のレイアウト。GTK+ベースでよく使われているlibgladeと殆ど同じですよ(XULがCSSを使ったGUIのデザインまでカバーしてる点等は違いますが)。

            ボタンが押された時のアクションなどのコールバックはJavaScriptなどDOMオブジェクト(Mozillaの場合はXPCOMオブジェクトで実装)を操作出来る言語にマップされます。まともなアプリケーションとなるとJavaScriptでカバーできるはずもなく、XPCOMを操れる言語であるC++やJavaで行うことになります。この時点でコンポーネントプログラミングの正体を始めてみた人なんかは、しばらく苦悶することだと思われます。まぁ、WindowsでActiveXをC++から書くのや、OpenOffice.OrgでUNOをC++で書くのと同じです。それにくらべればC#やVBやJavaScriptがいかに楽にコンポーネントを作成出来るかを思い知るでしょう。

            親コメント
          • .NET に近いというか、SOAP と XML-RPC はかなり前から Mozilla にバンドルされていて、それを使った XUL アプリケーションも出てきていたはず。

            Mozilla/XUL を使うと真面目なGUIとウェブとサーバーサイドロジックをスクリプトで結合できるので非常に楽しいです。IEコンポーネントを使ったブラウザが多数出たように、雨後の竹の子のようにこれを使ったブラウザ/アプリケーションが出るかも…
            親コメント
        • XUL がマッチしそうなアプリケーションって何かあるかな。

          アドベンチャーゲームはどうでしょうか。

      • by Anonymous Coward on 2002年12月05日 20時55分 (#212706)
        ブラウザ上の HTML Form を使う処理というと、HTML Form で
        UI を書いて、処理は HTML内の JS/VBS と Webサーバで実装
        しますよね。

        XUL は UI部品としても HTML Form よりもリッチな部品が
        ありますし、背景に処理も仕込めるので Mozilla Navigator
        や ChatZilla、OEOneデスクトップなどが出来るんですよね。

        あと、まだあまり実装例がありませんが、XULは Webコンテンツの
        ように扱うこともできるので、Java Applet を配布するがごとく
        XULコードを XREクライアントへ配布することもできます。

        Netscape 6 にWebページ翻訳機能がありましたが、あれを実行
        すると翻訳サーバから XULコードが送られてきて部分的に
        UIとして使われていました。

        また、似た事例として、九州工業大学のグループによる Web
        Application Framework for Toolkit-based GUI programming
        の SWT Component があります。 HTML Formでは機能不足なので
        XULを使った実装が行われているそうです。
        http://pcweb.mycom.co.jp/news/2002/11/05/12.html [mycom.co.jp]
        親コメント
  • by Anonymous Coward on 2002年12月05日 19時42分 (#212671)
    Opera Open The Web - 全てのブラウザに平等を [srad.jp]のトピと全く逆方向のネタが似たような時期に出て来たのが面白いなと思ってたりします :-)

    いや、逆方向はそれでもいいんですよ。
    ただ、これまでNetscapeやIEは「便利だからどんどん実装しちゃえ」とばかりに「標準」と「独自仕様」が曖昧(というかいっしょくた)なままに進化してしまったために「全てのブラウザに平等を」という話になっちゃった訳で、この辺の「標準と独自仕様の折り合いをどう付けるか」というのに興味があります。

    もちろん「XULとHTMLは別物だ」というのは理解していますが、XULに対応した別の実装が現れてきた時には、また「標準化」が必要になってくるでしょうし、XULもこれから進化して行けば同じMozillaでもバージョンの違いによって振る舞いが変わってくるかもしれない。
    そうなると、またHTMLと同じように独自仕様と標準化の追いかけっこが始まって、実装による差異が問題になってくるでしょう。
    そうなった時に、またHTMLと同じ事を繰り返してしまうのもアホらしいし、そこから抜け出すのにまた新しいものを作らなくてはいけないのでは進歩がありません。

    という訳で、私は「XULで(今)何ができるか」よりも「XULが(今後)どうなって行くのか」という点に興味がありますね。

    • もちろん「XULとHTMLは別物だ」というのは理解していますが、XULに対応した別の実装が現れてきた時には、また「標準化」が必要になってくるでしょうし、XULもこれから進化して行けば同じMozillaでもバージョンの違いによって振る舞いが変わってくるかもしれない。 そうなると、またHTMLと同じように独自仕様と標準化の追いかけっこが始まって、実装による差異が問題になってくるでしょう。 そうなった時に、またHTMLと同じ事を繰り返してしまうのもアホらしいし、そこから抜け出すのにまた新しいものを作らなくてはいけないのでは進歩がありません。

      • by Anonymous Coward on 2002年12月05日 21時15分 (#212718)
        XULもこれから進化して行けば同じMozillaでもバージョンの違いによって振る舞いが変わってくるかもしれない。
        XMLをよく理解していない発言のように見えて仕方ないです。 変更に伴うリスクがゼロだとはいいませんが、XMLに基づいた文書って、仕様変更にたいしてそれほどデリケートでしょうか?

        いえ、XML の部分としてはそれで良いでしょうが、XUL の場合は JavaScript の(実行プラットフォームの)挙動が実際 Mozilla のバージョンによって異なります。実に、Mozilla 1.0 と Mozilla 1.2.1 との間での互換性が保たれているわけではないのです。

        そのため、XUL の文法がフィックスされているからといって、必ずしも標準的な技術言語となるための基盤が整ったとは言えませんし、それにはまだまだ障壁が多いと言えるでしょう。

        何が必要かといえば、「アプリケーション実行環境でもあるブラウザ」ではなく、「ひとつの整ったアプリケーション実行環境」なのだと思います。これは、Gecko の上に乗っかるものにならざるを得ませんが、XRE はそういったものになるポテンシャルはあると思います。Mozilla 1.0 はその前者になるべきものだったのですが、実際にはそうなりませんでしたから。

        XUL が使い物になるには、それを支える XPCOM のほうがむしろ重要なポイントになるのではないでしょうか。

        親コメント
      • 旧仕様のソースを新仕様に適合させる事はおっしゃる通りそれ程難しくは無いですが、問題の本質は、仕様が変更されてもクライアントの環境が付いて来れない(ものもサポートしなきゃいけない)という事なんですよ。
        旧仕様のクライアントを強制的に新仕様のものに置き換えることは
        • 仰る意味がよく分からないのですが、その考察は XUL に対してというよりも、ECMA Script に対して(それとは自覚することなく)当てはまっているような気がしますが。どうでしょう?

          • 上のコメントではXULというのを「XULで記述された枠組み全体」の意味で書いています。
            ECMA Script(JavaScript)に対して当てはまるのは当然です。
            標準化/互換性を考えずに「便利だから」とか「これcoolじゃん」とか言ってどんどん新しい機能を付け加えて行くと、これまでのHTMLやECMA Script(JavaScript)と同じ羽目になっちゃうんじゃない?という話をしてるんですから。
        • ASPやPHPでも使って、クライアントのバージョンごとにふさわしいバージョンのXULを生成することですかね。世の常です。
  • by Anonymous Coward on 2002年12月05日 20時30分 (#212694)
    この手の仕組みを見ると GMW を思い出しちゃう私は古い人なんですかね。

    # G 言語だけで簡単なゲームくらい書けそうだし。
typodupeerror

犯人はmoriwaka -- Anonymous Coward

読み込み中...