21

現在、Qt 4.7 の一部としてリリースされるQtQuick (Qt User Interface Creation Kit) を評価しています。QMLは、QtQuick の背後にある JavaScript ベースの宣言型言語です。

これは非常に強力な概念のように思えますが、WPF のXAMLや Silverlight のような他のより成熟した宣言型 UI 言語を広範に使用したことがある人なら、この言語から得られる実際の利点について何らかの洞察を得ることができるのではないかと思います。このスタイルのプログラミング。多くの場合、さまざまな利点が引き合いに出されます。

  • 開発のスピード
  • プレゼンテーションとロジックを強制的に分離
  • コーダーとデザイナー間のより良い統合
  • UI の変更は再コンパイルを必要としません

また、デメリットはありますか？いくつかの潜在的な懸念事項が思い浮かびます。

  • 実行速度
  • メモリ使用量
  • 複雑さの追加

他に考慮すべき考慮事項はありますか？

4

4 に答える 4

13

（更新しました）

XAML に関する誤解は、コンパイルされていないということです。実際、BAML (トークン化されたバイナリの XAML) にコンパイルされます。どうやら、CAML と呼ばれる XAML の IL コンパイル バージョンもあったようです。OP は、XAML/BAML と CAML とは何かを説明するこの良い記事を教えてくれました。

とにかく、なぜそれを使用するのかという質問に対して：

XAML は単に C# オブジェクトのシリアル化形式であり、WPF GUI に見られるような階層オブジェクト構造を記述するのに特に適しています。

WPF が役立つのは、次のような退屈でない C# コードを書くことです。

var grid = new Grid();
grid.Content.add(new TextBlock() {Text = "Hello"});
grid.Content.add(new TextBlock() {Text = "World"});

次のように、より読みやすい方法で表現します。

<Grid>
  <TextBlock Text="Hello">
  <TextBlock Text="World">
</Grid>

WPF オブジェクトのネスト (他のオブジェクトの中に何かを入れること) は非常に深くなる可能性があるため、WPF は結果の C# コードよりもはるかに読みやすくなっています。

関心の分離に関しては、XAML はロジックではなく、オブジェクトとその関係/プロパティのみを表現できるため、ここでも役立ちます。そのため、UI レイアウトからロジックを分離する必要があります。MVVM パターンは、このタスクに非常に適しており、簡単にテストでき、ビューを交換できます。

C# の同じコードは XAML マークアップよりも簡単に複雑になるため、XAML で追加された複雑さも簡単に無視できます。

ただし、QTQuick についての洞察を提供することはできません。ごめん

于 2010-04-24T20:58:47.083 に答える
9

QtQuick は C++ プラグインを介して拡張可能です。実際に Qt 関係者が推奨しているのは、すべてのビジネス ロジックが C++/Qt にありながら、QtQuick/QML で UI、アニメーション、トランジションなどを行うことです。このようにして、両方の世界を最大限に活用し、通常のように C++ コードをデバッグできると同時に、UI の作成が楽で非常に簡単になります。

また、QtQuick/XAML に関するもう 1 つの重要な考慮事項は、これらがハードウェア アクセラレーションであるということです。たとえば、何の努力もせずにかなり良好な fps を取得できます。そのため、彼らは達成しようとしていることにまったく遅れをとっていません。

時間を大幅に節約できます。コード付きの UI を 3 日で作成し、QML でも同じことを 2 時間で行いました。

于 2010-06-18T05:16:06.990 に答える
7

宣言型コーディング (WPF や QTQuick など) のポイントは、開発者と、おそらくアプリケーションの視覚的側面を実装するアーティストとを分離することです。WPFに関しては、デバッグが少し難しくなっていることがわかりました。私たちが話している間、私は QTQuick を見るために最新の QT をコンパイルしています。(時間がかかりますし、stackoverflow を見る時間もあります :-) ) だから、それについてはまだ意見がありません。

于 2010-04-25T01:53:19.263 に答える
6

QML/XAML は次のとおりです。

  • MVVMパターンに最適
  • ハードウェア アクセラレーション (Windows、MAC、Linux、および電話 OS 用の OpenGL を使用した QML... Windows およびその電話バージョン用の DirectX を使用した XAML)
  • アーティストに近づく
  • XAML/QML を使用して優れた優れた UI を作成できます
  • より簡単な UI 実装
  • 素敵なアニメーションが可能
  • XAML では、通常、少し変更するだけでアプリケーションの Silverlight バージョンを作成できます。
  • XAML には、テンプレート、トリガー (DataTrigger、Trigger、EventTrigger)、バインド (いずれかの側、および両方の側を一緒に)、リソース、コマンド、DependencyProperty、および通知可能なプロパティなどの優れた機能がいくつかあります。

ただし、XAML で注意してください: (私は XAML プログラマーなので、QML のポイントはありません)

  • XAML のデバッグはできません
  • XAML を変更する場合は、すべてのプログラムを再コンパイルする必要があります

  • パフォーマンスにはより注意してください。たとえば、XAML で非常に多くの RoutedCommands を使用すると、アプリケーションが使用できなくなります。

  • XAML では、一部の機能が期待どおりに動作しません。残念ながら、いくつかのトリックがあります。(それは明らかなはずです...期待どおりに動作するはずです...そうではありませんか?)

  • BitmapEffect や Effect などの類似した名前空間には注意してください。機能も価格も違います。(たとえば、BitmapEffect にはソフトウェア レンダーの効果があり、Effect にはハードウェア レンダーの効果があります)

  • 現実の世界では、アーティストは WPF を Flash として使用できませんでした (少なくともパフォーマンスは良好でした)。

  • 一部の機能は特別な場所で動作します。たとえば、DataTrigger は Resource セクションではなく Style タグでのみ機能します。

  • XAML にはいくつかの弱点があります。いくつかの例: シーケンシャル アニメーションはありません... XAML で計算を行うことはできません (わずかな作業でも C# でコンバーターを作成する必要があります! JavaSript は QML の優れた代替手段です)... 一部の属性が重複しています。例 x:Name and Name... ViewModel からのビューの制御は明確ではありません。例: ViewModel から View を閉じる (CodeBehind が必要です)

  • 実行時エラーが多すぎます。間違った場所でタグを使用すると、構文エラーが表示されますが、多くのエラーは実行時にのみ発生します。たとえば、ColorAnimation の Background プロパティ (Background.Color ではなく) をターゲットにすると、正常にコンパイルされますが、アニメーションの実行中... BUMP... ランタイム エラー !!! このような場合、Expression Blend では、アプリケーションがクラッシュします!!!

于 2011-12-01T06:39:56.173 に答える