qtforum.de

Guten Morgen,

ich dachte ich erzähle in meinem ersten Post erstmal was, bevor ich loslege.

Ich arbeite zur Zeit an einem größeren Projekt. Bisher war geplant wxwidgets einzusetzen. Ich habe mit wx auch schon ein paar Kleinigkeiten realisiert und fand es in Ordnung.

Allerdings habe ich auch Qt im Auge gehabt und musste im Nachhinein feststellen, dass Qt verbreiteter ist und es scheinbar auch mehr Foren, Tutorials und Doku gibt. So ganz nebenbei habe ich im Bekanntenkreis nur Leute, die schonmal mit Qt gezaubert haben. Das Signal / Slot System

Nun hat sich das Projektteam vergrößert und irgendwie haben alle schonmal mit Qt gearbeitet. Na dann wechsle ich mal.

Wobei ich anmerken muss, dass die ganzen Einstellungen für ein Qt Projekt komplizierter sind als für wxwidgets.


Seis drum. Ich habe nun folgende Frage:

Angenommen ich habe Oberfläche und Arbeitspferd in zwei getrennten Prozessen. Im Arbeitspferd werkeln zusätzlich X Threads. In einem dieser Threads werden nun Bilder oder Graphen generiert. Diese möchte ich darstellen. Und das ohne großen Datenverkehr. Denn die Kommunikation /Oberfläche und Arbeitsprozess ist nicht direkt für die Worker-Threads zugänglich.

Diese Darstellung ist eigentlich nur für den Service Betrieb gedacht. Also kann ich die im Grunde von der Oberfläche unabhängig machen.

Wie mache ich nun aus einem Worker-Thread ein Darstellungsfenster auf, das ich verschieben und schließen kann und das eine Bildsequenz abspielt? Wichtig ist, dass dieses Fenster unabhängig laufen kann und mir nicht sblockiert. Ich denke am Besten ist es einen Thread anzuwerfen, der sich darum kümmert. Wie verpasse ich dem dann die Message-Queue des Fensters?

Es gibt nur einen Thread der Fenster öffnen/verwalten darf und das ist der Haupt-Thread.

Arbeite dich in die Grundlagen von Signals und Slots ein. Damit lassen sich auch Thread-Übergreifend Daten übertragen, ohne daß es eine Blockade eines Threads gibt und ohne daß man sich (mit den Standard-Qt-Klassen) um Locking kümmern muß.

War auch bis dato mein Wissen. Allerdings hat man mir gesagt, dass es mit Qt realisierbar ist und derjenige es schonmal gemacht hat. Allerdings sehe ich denjenigen erst in 2 Wochen wieder.

dass es mit Qt realisierbar ist und derjenige es schonmal gemacht hat.

Nein, hat er nicht.. denn:

Note 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.

http://doc.trolltech.com/4.3/threads.html

Aber das ist ja auch nicht notwendig.. siehe upsala..

Und eigentlich ist das mehr ne vereinfachung als eine Beschraenkung

auf der WInapi mit multithreading rumschreiben ist zwar schon cool aber das zu syncen, das da immer konsinstente Anzeigen entstehen ist meistens ned trivial ...
Am Ende hat man meist wieder nur einen thread der die Anzeige macht, und zig threads die dem "Commandos" etc schicken ...

Ciao ...