[Qt] QApplication im QThread
-
Hab schon einiges zu dem Thema gelesen aber sinnvolle Antworten finde ich nicht.
Ich hab ein "normales" Programm das jetzt um eine Qt-GUI erweitert werden soll. Allerdings darf das Hauptprogramm unter keinen Umständen geändert werden und muß auch völlig unabhängig von Qt bleiben. Das ist ja an sich kein Problem.
Allerdings lese ich ständig von Problemen wenn man QApplication in einem QThread laufen läßt. Verursacht schwarze Löcher, Pest, Steuer usw. Genaueres zu den Problemen findet sich aber nicht.
Aber es funktioniert, und das ohne jegliche Warnings. Momentan habe ich es so gebaut das eine Schnittstelle einen QThread startet, in dem QApplication initialisiert und auch die eigentliche GUI erstellt wird. Der Rest des Programms läuft also weiter im Main-Thread.
Gibt es da Probleme? Denn es läuft wie gesagt, nur will ich nicht das mir das irgendwann um die Ohren fliegt. Die GUI soll auch nicht irgendwie nach draußen kommunizieren (über Signale), da sich die Hauptapplikation schon alle Daten rausholt.
-
Passiert das unter allen Betriebssystemen?
Da unter Linux sich der Main-Thread von anderen Threads nicht unterscheidet kann ich mir das kaum vorstellen.
-
GUI-Opperationen sollten in dem Thread ausgefuehrt werden, in dem auch QApplication::exec() aufgerufen wurde. Dieser ist ja in der Regel der main-thread.
Das, was du da gebaut hast, wird aber von Qt selbst nicht unterstuetzt also kann es leicht sein, dass es nur auf der aktuellen Plattform funktioniertNote that QCoreApplication::exec() must always be called from the main thread (the thread that executes main()), not from a QThread. In GUI applications, the main thread is also called the GUI thread because it's the only thread that is allowed to perform GUI-related operations.
-
Unter Linux geht es momentan. Hab gelesen das es unter Mac Probleme gibt (was mir letztendlich vollkommen egal ist, da es dort nie laufen wird), nur wäre es eben gut zu wissen ob das so gewollt ist oder ich beim Umstieg auf neuere Qt-Versionen (momentan ist 3.x) böse Überraschungen erwarten darf.
Bei Trolltech selbst lese ich immer nur was von GUI-Thread und Event-Thread, das das die gleichen sein sollten. Ist momentan ja auch der Fall bei meiner Konfiguration.
-
zwutz schrieb:
GUI-Opperationen sollten in dem Thread ausgefuehrt werden, in dem auch QApplication::exec() aufgerufen wurde. Dieser ist ja in der Regel der main-thread.
Das, was du da gebaut hast, wird aber von Qt selbst nicht unterstuetzt also kann es leicht sein, dass es nur auf der aktuellen Plattform funktioniertNote that QCoreApplication::exec() must always be called from the main thread (the thread that executes main()), not from a QThread. In GUI applications, the main thread is also called the GUI thread because it's the only thread that is allowed to perform GUI-related operations.
Und genau das macht mir Sorgen. Denn ich habe hier nur zwei Möglichkeiten bei der Applikation die ich bastel:
a) Einen QThread erstellen und darin QApplication->exec() aufrufen und alles drin ablaufen zu lassen
b) Eine QApp erstellen und dann im QThread die GUI laufen lassen
c) QApp und GUI im main-Thread starten, Rest des Programms im Thread laufen lassenc) geht nicht, weil ich an main nicht einmal rankomme
b) geht in Qt nicht, müssen exec() und GUI im gleichen Thread sein
a) Geht, aber anscheinend auch nicht erlaubt...Da muss es doch eine sinnvolle Möglichkeit geben. Sonst müsste ich letztendlich einen komplett eigenen Prozess schreiben und IPC nutzen. Wäre in meinen Augen aber sehr nervig.
-
Die frage iss ned ob nerfig oder nicht, sondern ob notwendig, und in dem falle sicher ja.
Probier das mal unter windows ! und schildere deine resultate !
geht nicht, weil ich an main nicht einmal rankomme
Das heisst eigentlich dass deine Application deinen Code ueber pluginschnittstelle (im weiteren Sinne) anzieht oder ? Also du implementierst ne .so und das Prog zieht die an und springt mit ner einsprungfunktion (in nem eigenen Thread) deinen Code an ?
Unter Windows wuerdest da wahrscheinlich nicht mal nen qt applicationsobject installiert bekommen.Also IPC unvermeidlich ...
kannst es dir ja vereinfachen, und die ausgabe auf die console schreiben, und dann drummherum ne application in QT, die deine Fremde App in nem QProcess startet und den output auswertet.
Ciao ...
-
Ist kein Plugin, nur schreibe ich nicht die main. Aufgrund von Sicherheitsbestimmungen usw. und bla bla bekomm ich hier nicht das ganze Programm, sondern muss nur einen Teil bereitstellen. Und main etc. gehört da leider nicht dazu.
Unter Windows kann ich das nicht testen, da ich gar kein Windows habe. So wie ich das mitbekommen habe, wird es aber eh nur unter Linux laufen, fraglich ist aber eben die "Zukunftssicherheit". Bisher läuft es nämlich.
Aber da man sich momentan schon schwer beim Wechsel zu Qt4 tut, mag es sein das sich die Frage nicht so schnell stellt.
Bei QProcess ist eher das Problem das hier zur Kommunikation über stdout und stdin wieder die Event-Loop und somit QApp benötigt wird und das gleiche Problem auftritt.