nachdem ich nun einen großen Teil meines bereits geschriebenen Codes wegschmeissen musste, frage ich hier doch mal lieber die MVC-Profis, wie man das anpacken muss.
Ich habe eine Dateisystemartige Struktur der Daten. Das heisst, Verzeichnisse und Unterverzeichnisse, sowie Dateien in Verzeichnissen. Der Verzeichnisbaum soll (ohne Dateien) in einem QTreeView dargestellt werden, in einem separaten QTableView sollen die Dateien des gerade im QTreeView selektierten Verzeichnisses zeilenweise dargestellt werden (Die columns also z.B. Dateiname, Typ, Größe, Änderungsdatum etc.). Später soll auch Drag&Drop von Dateien in Verzeichnisse möglich sein, also von QTableView ins QTreeView, sowie von Verzeichnissen in andere Verzeichnisse, also innerhalb QTreeView. Das ist aber erstmal Zunkunftsmusik.
Nun möchte ich das Ganze in Model/View aufbauen, da die Tree-/TableWidget-Komponenten doch recht unpraktisch sind (z.B. fehlen ordentliche Signale wenn z.B. im TreeWidget ein Verzeichnis in ein anderes verschoben wurde etc.).
Mein erster Gedanke war zunächst ein QAbstractItemModel zu schreiben, welches die Verzeichnisse und die Dateien beherbergt. Nun muss ja an das TreeView andere Daten gereicht werden als an's TableView, sie können also wohl nicht beide auf dieselben data(), rowCount(), etc. Funktionen zugreifen. Muss ich also zwei ProxyModels schreiben, welche die Daten vom zentralen Model entsprechend filtern/aufbereiten?
Eine weitere Unklarheit besteht bei mir darin, wie ich die Daten überhaupt im Model speichern soll. Brauche ich hierzu selbst nochmal eine Art Datenverwaltungsklasse, welche die Baumstruktur hält, also z.B. MyTreeItem mit QList felder für Dateien und weiteren MyTreeItem-Unterverzeichnissen? Und soll dann von außen via QModelIndex::internalPointer() auf die MyTreeItems des jeweiligen Modelindexes zugegriffen werden? Bin etwas verwirrt, wie man vermutlich merkt.
Die Docs zu Model/View hab ich schon gewälzt, leider beschränken sich die Trolls ja auf die banalsten Beispiele mit jeweils einem View und einem simplen ListModel o.Ä. . Wenn sie einen schon mangels ordentlicher Alternativen zu M/V nötigen, sollten sie wenigstens die docs gescheit ausarbeiten
Danke schonmal für jegliche Hilfe in diesem M/V-Sumpf.
MfG, Spinoza