GUIアプリケーションのアーキテクチャ

Question

GUIアプリケーションを書いています。次の構造を実装したい：

プロジェクトツリータイプと動作が異なるノードを使用（つまり、右クリックまたは選択すると、異なるメニューオプションが表示される場合があります）
編集領域を追加するために、垂直方向および水平方向に動的に分割できるエディターウィンドウ。各編集領域はプロジェクトツリーの1つのノードに対応します。

私はc ++/qtを使用していますが、プログラミング言語やライブラリではなく、設計に問題があります。

現在、プロジェクトツリーを実装するために、親と子へのリンクを含むツリーノードの抽象インターフェイスを作成しました。特定のタイプのノードごとに、新しいクラスを作成します。私はQtを使用しているため、ビューと実際のツリーの間の中間オブジェクトのように機能するモデルがあります。視覚的な表現からの情報がこのツリーに漏れることはないようです。

実装に関して次の問題があります。

このツリーをすべてのデータのホルダーとして使用することは適切ですか？これを使用して、編集中のオブジェクトに関する情報を保持できますか、それともすべてのデータに外部ホルダーを使用しますが、ノードからそれにリンクしますか？
1. オブジェクトに関する情報、つまりオブジェクトにすでに渡されている視覚的表現に関する情報を保持している場合（ツリーの構造を知っています）。
2. 外部ホルダーへのリンクの場合、そのようなリンクを作成する方法を理解できず、ノードの動的な作成/削除をサポートできません。
ビューアイテムをクリックすると、ノード内のデータを何らかの方法で選択して編集用に開く編集領域。
1. 特定のタイプのノードにdynamic_castして、その内部情報を現在選択されている編集領域に渡さない限り、その方法を理解できません。
2. 私の頭に浮かぶもう一つの見栄えの悪いアプローチは、ノードに仮想関数を導入することですが、ノードは視覚的表現に関連しているため、この関数のロジックを実装することはできません。

ツリーの例：

モデルは、独自のベクターグラフィックエディターで編集できるエンティティです。マテリアルは、テーブルのようなキーと値のプロパティで、各キーはグラフィックエディターのいくつかのプリミティブにアタッチできます。

Doc Brown · Answer

そのデータ自体がほとんどツリー構造から独立している場合は、UIとデータを明確に分離するのがおそらく最善です。だからあなたの最初の質問への答え

すべてのデータに外部ホルダーを使用する必要がありますが、ノードからそれにリンクします

明らかに私見です "はい、絶対に"。 UIに依存しないオブジェクトモデルまたはリポジトリにデータを保持し、各ノード（UIの一部として解釈する）に関連オブジェクトへのリンク/ポインター/スマートポインターを保持させる必要があります。そのようなリンクを作成または管理する方法が現在わからない場合は、Qtドキュメントをさらに詳しく調べるか、Googleに問い合わせる必要があります。私はQtの専門家ではありませんが、オブジェクト（または任意のQtオブジェクトへのリンク/スマートポインタを保持できる QStandardItem の特別なサブクラスを派生する必要があると思いますUIのツリーノードを表します）。多分これ older SO post が役立つでしょう。

編集の問題では、UIノードを表すクラスは、正しいエディターオブジェクトへの2番目のリンクも保持できます。そのため、動的キャストなしで関連データの正しいエディターを呼び出すメソッドをそのサブクラスに実装するのは簡単です。正しいエディタを対応するデータオブジェクトとペアにする必要がある場所は、ツリーノードアイテムが構築される場所です。

Caleth · Answer

「私のGUIライブラリには、すべてのニーズを満たすコンポーネントが含まれていない」という一般的な答えは、GUI要素のコレクションを組み合わせて、目的の機能を実行することです。複数の場所でこれが必要な場合は、新しいコンポーネントとしてパッケージ化できます。ゼロから完全にコード化されているGUI要素はごくわずかです。コンボボックスがどのように実装されているかを考えてみましょう。それはボタン、ライン編集、ポップアップメニュー、そしていくつかの接続です。

この場合、表示するデータを選択するためのツリービュー（QTreeViewまたはQTreeWidget）と、特定のデータ（QStackedWidgetまたはQMDIArea）。

その場合、ツリーノードのデータはidentify描画するデータのみを必要とします。選択が変更されると、スタック上の関連フレームがアクティブになり、データソースから読み込まれます

user1118321 · Answer

個人的には、ドキュメントモデルを正しく理解していれば、ツリービューはこの仕事に適したツールではないと思います。「素材」はワードプロセッサのテキストのスタイルに似ているようです。「モデル」は、ユーザーが操作したいものの中心であり、ワードプロセッサで単語にスタイルが適用されるのと同じように、モデルにマテリアルを適用しているようです。たとえば、スタイル付きの同じツリー構造でページが表示されるワープロを見たことがありません。

したがって、同様の方法でデータをモデル化することを検討します。私はドキュメントオブジェクトを持っているでしょう。ドキュメントにはマテリアルのリストがあり、それぞれにnotというIDがリスト内のインデックスに含まれます。次に、ドキュメント内に完全に別のモデルのリストを作成し、モデルはそのIDでマテリアルを参照します。マテリアルのIDをリスト内の位置から分離することにより、ユーザーが2つの既存のIDの間に新しいIDを追加した場合、後のマテリアルを使用するすべてのモデルを更新する必要はありません。

次に、特定のドキュメントのモデルとマテリアルを一覧表示するための個別のUIを用意します。たとえば、Microsoft Wordには、適用可能なすべてのテキストスタイルを含むポップアップメニューと、新しいスタイルを作成するか、既存のスタイルを編集するオプションがあります。それがあなたがここで必要とする正確なUIであるかどうかは議論の余地がありますが、それらを分離するいくつかの方法は私には理にかなっています。マテリアルが階層的である場合（マテリアルBがすべてのマテリアルAのプロパティを継承し、いくつかの新しいプロパティを追加するなど）、ツリービューはマテリアルのみに適しています。そうでない場合は、リスト、テーブル、ポップアップメニュー、コンボボックスなど、何らかのリストが適切です。