6

C++ 型の属性を QMLに公開する時点で、 QMLで使用されるクラスはQObjects でなければなりません。QObjects非s (別名 POCO、 から派生したものでQObjectはなく、Qt メタシステムに登録されている)を使用できる可能性はありますか?

そうでない場合、オブジェクトを QML に準拠させるための単純な汎用ラッピング システムはありますか。私が考えることができるのは、動的プロパティを単純な に追加することQObjectです。

または、暗黙的に QML 準拠の型に変換する方法があるので、ラップする必要はまったくありませんか?

4

1 に答える 1

2

これは実際に 1 つのホットなトピックです。

独自の POD を登録して、ito の周りや QML 側で渡すことができると思います (ブラック ボックスと同じように、メンバー アクセスなしで、試したことはありません)。メンバーにアクセスするには、QML シングルトンのメソッドの形式で、またはインスタンスごとのラッパーとして効果的に機能する QtObject の子孫で、いくつかの get/set ラッパー コードを使用できます。

動的プロパティは現在サポートされていません -- おそらくいくつかの非常に奇妙なトリックでそれらを動作させることができますが、おそらく価値はないでしょう (しかし、プロパティにバインドしたくない場合は、物事ははるかに簡単になり、それはまだQObjectsになります）。

暗黙的な変換は、ある種のプリプロセッサを持つことを意味します (これはおそらく実行可能ですが、多くの時間がかかり、結果を Qt に戻す (そしてそれを生涯サポートする) ための判断が必要になります)。

私はこのように行きます：

  • 問題のオブジェクトが QObjects である可能性がある場合は、パフォーマンスを測定します (問題がなければそのまま使用します)。
  • そうでない場合は、不透明な POD を値で渡してみてください。機能する場合は、ラッパーの足場を作成し、以前のオプションよりも高速であるか、メモリ使用量が優れているかを確認してください。
  • プロパティへのバインディングが不要で、ダイナミズムが必要な場合は、a) ネストされた QVariants b) 動的な QObject プロパティを調査します
  • 極端な速度/メモリ要件を満たす必要がある場合は、ラッパーを自動生成するツールを作成し、それを Qt プロジェクトのビルド パイプラインにフックすることを検討してください。

つまり、カスタム POD は、組み込みのサポートと同じレベルのサポートを享受しておらず、標準的な言語プラクティスは、ガベージ コレクションされた QObject インスタンス (もちろん、どこでもポインターによって渡されます) を操作することを中心に構築されています。型のプロパティを変更します:

  • ポッド
  • リスト
  • QObject
  • バリアント (メンバーの変更を監視しない、iirc)
于 2013-10-14T19:18:09.453 に答える