ダン、それはそれを行う方法ですが、私はそれが正しいか間違っているかを考慮せずに「ただそれを行う」方法だと思います. さらに、あなたのソリューションが間違っていると言っているのではありません。アプリケーションをそのように実装すべきではないと私が信じる理由を説明しようとしているだけです。
まず、Qt Quick は、その名の通り、ユーザー インターフェイスをすばやく作成できるように設計されています。Qt デスクトップ ウィジェットをグラフィックス シーンに埋め込もうとすると、API を QML 環境にエクスポートしてすべてを機能させるという追加の作業が必要になります (タスクによっては、かなり大きな作業になる場合があります)。QML アプリケーションのアーキテクチャは、デスクトップとは大きく異なります。たとえば、model-view-controller を使用する場合、QTreeView と QItemDelegate を QML にエクスポートして機能させると、非常に複雑なソリューションになる可能性があります。実際、その概念に従う場合、最も簡単な方法はすべての UI を C++ バックエンドで作成し、最終的なソリューションを QML にエクスポートすることですが、実際にはQML をまったく利用しないデスクトップ実装。そのように実装する場合、QML と同じ「流動的な」効果を提供する Qt Animation API を使用する方がはるかに簡単ですが、純粋に QGraphicsView を使用するだけです。
第二に、QGraphicsView で既存のデスクトップ ウィジェットを使用する場合は、それらを「プロキシ ウィジェット」として埋め込む必要があります。これは、Qt Quick と QML に取り組んでいる Nokia の担当者によると、パフォーマンスに大きな問題があります。
第三に、QGraphicsWidget アプローチを使用する場合、Qt には QGraphicsWidget ベースのウィジェットがないため、すべてのウィジェットを最初から実装する必要があります。プッシュ ボタン ウィジェットのような単純なものでも、すべてのコードを自分で記述する必要があります。
第 4 に、Nokia が以前に述べたように、彼らは Qt デスクトップ サポートをサード パーティの会社に引き渡し、Qt Quick に全力を注いでいると説明しました。だから私はあなたのアプリケーションの保守性について考えます。さらに、今後の QML シーン グラフでは、すべての QML API がその実装に移行されますが、デスクトップ ウィジェットを使用できるかどうかはわかりません。