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.__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.
Was ich gelesen habe ist, dass QT wohl automatisch entscheiden kann, wann es welche Art von Verbindung braucht. Ist das immer so?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
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.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.
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.