Erweitern eines QAbstrackListModel um eine QList von Struct

Throndar

Hallo,

ich habe mir für mein Projekt ein eigenes Clientmodel (abgeleitet von QAbstractListModel) erstellt das aktuell eine Anzahl an Objekten Cliententhält. Jeder dieser Clients hat diverse Einstellungen die aus einfachen Datentypen besteht (Adresse, Port, Name, usw..)

Jetzt wollte ich im nächsten Schritt das Modell um eine Liste (oder Vector, oder QList, da bin ich noch nicht sicher) von Structs erweitern die Daten zu einzelnen Tracks auf den Clients enthalten sollen in der Art:

struct Track {
    QString contentSource;
    int type;
    double lenght;
    double framerate;
    int width;
    int height;
};

nur hänge ich jetzt an der Stelle die herangehensweise ist. Bei den einfachen Datentypen habe ich für das Element die Getter/Setter Methoden erstellt. Im Model dann in einem enum die Role festgelegt.

In der Funktion setData dann den Index, den Value und die Role übergeben, damit die Funktion für set aufgerufen, den Parameter übergeben und damit gesetzt.
In datahabe ich das ganze per Role und Modelindex ausgelesen. Nur überlege ich jetzt wie ich das ganze für Elemente erledige wie den Track von dem es mehrere pro Client geben kann (0 - n).

Ich hatte mir überlegt statt dem "setTrack" evtl. eine Funktion "addTrack" zu definieren der ich dann immer einen Wert übergebe für einen Track. Wobei ich aber statt einem Value ja (Beispiel oben) 6 Werte hätte. Dazu kommt das ich die Tracks auch irgendwie wieder zurück bekommen müsste beim auslesen.

Ich hoffe hier hat jemand einen Tipp für mich.

raven-worx

@Throndar
also eine QTreeView?
Hauptebene wie bisher (Clients). Jeder dieser Clients kann 0..N Unterebenen haben?

TreeModels verkomplizieren die Model-Implementierung erheblich, dafür lohnt es sich mit einer übersichtlicheren Darstellung.

Siehe SimpleTreeModel example

Throndar

Hallo @raven-worx ,

ich bin nicht sicher ob eine Baumstruktur da richtig ist weil scheinbar im vergleich zu meinem Listmodel doch sehr komplex, der Ansatz klingt aber interessant.
Aktuell habe ich ja mein ListModel. In dem ListModel liegen Objekte vom Typ Client und wenn möglich würde ich das gerne behalten und erweitern weil das genau so funktioniert wie es soll. Ich kann Clients eintragen, entfernen und alle Eigenschaften bearbeiten (auch aus dem QML was der Grund war das ich überhaupt ein eigenes Model gebaut habe).

Ich habe gerade deinen Link angeschaut und wenn ich es richtig sehe ist das Model für den Baum ein QAbstractItemModel, das würde doch bedeuten das der ganze bisherige Aufbau überflüssig ist und ich komplett von vorne beginnen muss?

Weil ich eigentlich bei einem bestehenden Client nur eine Liste von Objekten oder Structs (je nach dem was sinnvoller umzusetzen ist) hinzufügen möchte, sozusagen:

Client 1:

Track 1 (Name, Dauer, Typ)
Track 2 (Name, Dauer, Typ)
Track 3 (Name, Dauer, Typ)

Client 2:

Track 1 (Name, Dauer, Typ)

raven-worx

@Throndar
dann 2 listen nebeneinander.
Wobei die zweite (Track) Liste immer die Daten der Selektion der ersten (Client) Liste anzeigt?

Throndar

Hallo @raven-worx

das klingt sehr gut mit den zwei Listen.

Ich hatte mir zwar nochmal das TreeModelBeispiel angeschaut aber keinen Ansatz gefunden wie ich das umsetzen könnte auf mein Model wo ja verschiedene Objekte in eine Liste anderer Objekte gepackt werden müssten (jeweils die Liste von Track-Objekten in das Model mit den Objekten Clients).

Da ich von der verschachtelung abgekommen bin, bin ich gerade am überlegen wie man so etwas mit den zwei Listen umsetzten könnte. Ich hatte zuerst überlegt ob ich ein ListModel ähnlich dem meiner Clients für die Tracks verwenden kann. Dann müsste ich aber eine Instanz des Models für jeden Client erstellen, wo ich wieder das Problem habe wie ich die anschließend ansprechen bzw abfragen könnte.

raven-worx

@Throndar said in Erweitern eines QAbstrackListModel um eine QList von Struct:

Ich hatte mir zwar nochmal das TreeModelBeispiel angeschaut aber keinen Ansatz gefunden wie ich das umsetzen könnte auf mein Model wo ja verschiedene Objekte in eine Liste anderer Objekte gepackt werden müssten (jeweils die Liste von Track-Objekten in das Model mit den Objekten Clients).

Wie im Beispiel wird eine TreeItem erstellt und mit jedem QModelIndex (im internalPointer) gespeichert. In das TreeItem kannst du ja nach belieben reinpacken was du willst.

@Throndar said in Erweitern eines QAbstrackListModel um eine QList von Struct:

Da ich von der verschachtelung abgekommen bin, bin ich gerade am überlegen wie man so etwas mit den zwei Listen umsetzten könnte. Ich hatte zuerst überlegt ob ich ein ListModel ähnlich dem meiner Clients für die Tracks verwenden kann. Dann müsste ich aber eine Instanz des Models für jeden Client erstellen, wo ich wieder das Problem habe wie ich die anschließend ansprechen bzw abfragen könnte.

Es reichen doch 2 Models.
Das eine Model (hast du bereist) beinhaltet alle Clients.

Das zweite Model erwartet sich einen Client Objekt und zeigt seine Daten an.
Da kannst du zum Beispiel seine setClient() methode wie folgt implementieren:

void TrackModel::setClient(Client* client)
{
    this->beginResetModel();
    m_Client = client;
    this->endResetModel();
}

Die reset methoden sagen der view dass sich sie sich die Daten (inkl. row-count, etc.) neu holen soll.

Throndar

@raven-worx

du hast mich gerade auf eine gute Idee gebracht. Und zwar ist die grundlegende eine einzige Tracklist zu haben sogar richtig gut. Wenn ich die Tracklist beim auswählen eines Client in der Liste leere und dann jedesmal frisch einlese hat das sogar den Vorteil das ich immer eine aktuelle Trackliste zur Verfügung habe und nicht gefahr laufe das jemand am Client etwas gelöscht hat seit dem ich die Daten abgefragt habe. Und da die Tracks sowieso immer nur für einen ausgewählten Client angezeigt werden währe die Liste ja immer aktuell für das aktuelle Target.

Throndar

@raven-worx da haben sich unsere Antworten überlagert,

ich gehe gerade deinen Post durch, danke schon einmal für deine Mühe.

Deine Aussage zu den zwei Models bezieht sich darauf das ich mein bestehendes Listmodel belasse und es um ein weiteres Model erweitere um die Trackfunktionalität herzustellen?

Wenn ich dich richtig verstanden habe meinst du das ich mein Model lassen könnte wie es aktuell arbeitet und ein zusätzliches erstelle was die Tracks beinhaltet für den aktuellen Client. Dieses Model würde ich dann mit einer QList<Track> m_tracks füllen die alle Tracks des Client enthält.

Einzig den Teil mit dem "erwartet ein Client Objekt" mit deinem Beispielcode für setClient hat mich verwundert weil doch in dem Model der Tracks doch nur die Daten für den einen aktiven Client vorhanden sind.

Oder meinst du in dem zweiten Model wirklich für alle Clients alle Tracks hinterlegen?

raven-worx

@Throndar said in Erweitern eines QAbstrackListModel um eine QList von Struct:

Deine Aussage zu den zwei Models bezieht sich darauf das ich mein bestehendes Listmodel belasse und es um ein weiteres Model erweitere um die Trackfunktionalität herzustellen?
Wenn ich dich richtig verstanden habe meinst du das ich mein Model lassen könnte wie es aktuell arbeitet und ein zusätzliches erstelle was die Tracks beinhaltet für den aktuellen Client. Dieses Model würde ich dann mit einer QList<Track> m_tracks füllen die alle Tracks des Client enthält.
Einzig den Teil mit dem "erwartet ein Client Objekt" mit deinem Beispielcode für setClient hat mich verwundert weil doch in dem Model der Tracks doch nur die Daten für den einen aktiven Client vorhanden sind.

ist schon richtig so.
In meinem Beispiel übergibst du halt einen Client. Was du dir dann daraus rausziehst ist dir überlassen ;)
Vielleicht möchtest du dich ja auch noch an irgendwelche signals connecten, etc. ... War nur ein Beispiel. Wenn die eine QList<Track> ebenfalls reicht, gut.

Throndar

Hallo @raven-worx ,

vielen Dank nochmal für deine Erläuterung.
Ich denke deine Idee (besonders der Tree-Ansatz) wäre an der Stelle die sicherlich elegantere Lösung zur Umsetzung der Client-Tracks und das werde ich sicher noch versuchen umzusetzen.

Für den ersten Schritt um es erstmal in Funktion zu bringen werde ich den Vorschlag mit dem zweiten Model das die Daten des aktuellen Clients enthält versuchen umzusetzen. Das bringt den schon erwähnten Vorteil das es (halbwegs) aktuell ist da es beim auswählen "frisch" erstellt wird (und was noch fast wichtiger ist, ich habe eine Vorstellung wie es funktioniert ;) )

Nochmals Danke, du hast mir sehr geholfen!