13

XulRunner / Geckoは、GUIを多用するアプリケーションを開発するのに非常に興味深いようです(HTML / CSS / SVG / XUL / Javascriptなどの広く使用されているテクノロジーを使用することにより)。しかし、基盤となるC ++ API(XPCOM、NECKOなど)は非常に古くて複雑に見えます。さらに、ドキュメント/開発者ツールの一般的な欠如は本当に恐ろしいものです。

一方、QTは非常に優れたプラットフォームを備えており、十分に文書化され、サポートされています。ただし、UI部分は実際には「従来型」です。

特にQT/GTK /MFCなどの他のC++デスクトップアプリケーションフレームワークと比較して、XULRUNNERでのあなたの経験は何ですか...?何が欠けている?何がすごいですか?

副次的な質問:既存のMFCアプリをクロスプラットフォームのC ++デスクトップアプリケーションフレームワークに移行したい場合、QTやGTKの代わりにXULRUNNERを使用するのが賢明ですか?

4

5 に答える 5

7

正直なところ、XULRunnerアプリがあまりないことに同意しません...たくさんあります。これらはMozillaが知っているもののほんの一部です。

https://developer.mozilla.org/en/xulrunner_hall_of_fame

developer.mozilla.org/en/List_of_Mozilla-Based_Applications

もちろん、これにはFirefoxとThunderbird自体は含まれません。

私たち自身はそこにリストされていますwww.redbacksystems.com/liaison/

私は2003年頃からこのプラットフォームで開発を続けており、他のプラットフォームでプログラムすることは絶対にないという選択を考えると、このプラットフォームが大好きです。

XBL(1.0ではありますが)、RDF、XMLテンプレーティング、リモート更新、プラグイン、拡張機能のサポートなどなど、ジオロケーションやネイティブSQLのサポートを開始することすらありません。

かなり完全なXULRunnerアプリを数日以内にブートストラップできない場合は、何かひどい問題がある可能性があります。デプロイメントプラットフォームに関係なく、その他のコーディング作業が必要になります。

私にとって、Mozillaツールキットは選択の余地のないプラットフォームです。

ところで、私が理解しているように、Joostは独自のビデオレンダリングを作成/実装し、コンテンツもDRMしようとしていたため、特定の課題がありました。

于 2010-06-22T08:42:59.397 に答える
6

私の知る限り、XulRunnerを使用して構築されたアプリケーションは実際にはそれほど多くありません。私はそのうちの1人の技術リーダーであり、経験豊富な人材を採用しようとしたので、知っておく必要があります。後から考えると、これは私を驚かせません。XulRunnerを使用するという私たちの決定は、私のアドバイスに反して、開発者以外の人によって行われました。多くのことは、以前使用していたwxWidgetsの場合の2倍の時間がかかりました。今では他のプロジェクトでもQtを使用していますが、wxWidgetsよりも優れていると言わざるを得ません。したがって、QtはXulRunnerの2倍以上の効率があり、さらに経験豊富な開発者を見つけるのがはるかに簡単になると、かなり確実に述べることができます。

確かに、XulRunnerのJavascriptは素晴らしいです。ただし、QtにはJavaScriptCoreをラップするQtScriptも付属しています。そして、真にリッチなUI(つまり、単なる画像のスタック以上のもの)を構築することになると、HTML + SVG + CSS+JSはそれをカットしません。それらは、複雑なことを可能にするのではなく、単純なことを簡単にするために開発されました。最新の機能であるビデオをご覧ください。HTML5のソリューション:タグ、そして舞台裏でいくつかのC++コードに実際の作業をさせます。ビデオは一度に1つずつ表示される画像の大きなスタックですが。

ですから、問題はそれほど多くないので、足りないものがあります。開発が遅く、結果も遅いというだけです。

素晴らしい面では、プラグインメカニズムは実際には非常にうまく機能します。

さて、最初から始める場合、これはすべて当てはまります。すでに多くのMFC/C ++コードがある場合は、C ++を使用して、MFC部分のみを削除してください。つまり、QtまたはおそらくwxWidgetsが明らかに勝者です。

于 2010-04-14T13:18:51.250 に答える
2

実際にC++でXULコードを書きたくないと思います。XPCOMなどのAPIの目的は、既存のCライブラリとインターフェイスできるようにすること、またはJavaScriptエンジンの外部でAPIを呼び出す必要があるプラットフォーム固有のものを作成する必要がある場合に使用できるようにすることです。

クロスプラットフォームのGUIアプリをJavaScriptで記述したい場合は、探しているものかもしれませんが。

于 2010-04-13T20:21:16.743 に答える
1

私はそのチームにはいませんでしたが、joostデスクトップアプリケーションはUIにXULRUNNERを使用していました。これはオプションですが、個人的にはクロスプラットフォームGUI用のスティックで触れることはありません。実際、私の経験では、単一のクロスプラットフォームアプリを使用することは常に標準以下であることが示されています。

私の提案:コアアプリの機能を分割し、必要なプラットフォームに合わせてネイティブUIを構築します。はるかに優れたユーザーエクスペリエンスが得られます。

于 2010-04-13T21:18:58.477 に答える
0

誰かがこれを試しましたか?

XULビューアー http://code.google.com/p/xulwin/

これはかなり素晴らしいプロジェクトです。クリーンなコード、いくつかの依存関係(poco-basicとboostのみ)

うわー!

于 2010-08-04T17:25:29.590 に答える