__deets__ hat geschrieben: ↑Freitag 12. April 2019, 14:11
Qt und threading sollten da genug liefern, die originale Dokumentation hat da einiges an Beispielen und Erklaerungen. Und eine Queue ist doch ausreichend, alles, was da reingestopft wird, erledigt irgendwann der Worker-Thread.
Bin da mittlerweile etwas schlauer geworden und ich danke das bekomme ich hin. Mit der Queue ist es bei meinem Fall halt so, dass sich darin immer nur ein Objekt, das aktuelle, drin befinden darf. Habe mir gedacht, dass ich das so lösen könnte, dass mein WorkerThread jedes mal wenn er eine Zeile abgearbeitet hat ein Signal schickt, welches veranlasst dass ein neues Objekt in die Queue geschoben wird.
Signal/Slot-Verbindungen KOENNEN thread-sicher sein, die Bedingungen unter denen das so ist werden in der Dokumentation erklaert, das sind dann sogenannte "Queued Connections". In einem anderen Zusammenhang habe ich dazu mal Beispiele gebaut:
viewtopic.php?f=24&t=44250&start=15#p335559
Was ich gelesen habe ist, dass QT wohl automatisch entscheiden kann, wann es welche Art von Verbindung braucht. Ist das immer so?
Und was das Modell angeht: da sprach in von einem QAbstractItem-Model, welches du an deinen View binden kannst, und das damit sauber Daten von Darstellung trennt. Klassisches "Model View Controller"-Pattern halt, wie schon in den 90ern beliebt.
Verstehe jetzt besser warum man das so macht. Habe auch angefangen wieder ein QTableView mit einem QAbstractTableModel zu nehmen. Glücklich bin ich damit allerdings noch gar nicht. Es gibt nicht viel Beispiele im Internet dafür, mein Code wird um einiges komplexer und für die Spinner und Comboboxen brauche ich QItemDelegate um die in die Tabelle zu bekommen.
Weiß echt nicht, ob sich der Aufwand in meinem Fall lohnt. Im Schnitt hat meine Tabelle vielleicht 1-7 Zeilen, wenn's mal hochkommt 20-25.