[QT 4] threading in updatanje widgetov

V QTju sem še bolj nov in imam sledeč programček. Naredim en QThread, v katerem se opravijo časovno zahtevne operacije ter brskanje po disku. Ta thread opravlja tudi malo logginga v en read only QTextEdit. Takoj po tem, ko thread poženem, poženem tudi glavni GUI thread (app.exec()). Do sem vse lepo in prav. Ampak tale logging se ne izpisuje na ekran. Tudi če explicitno kličem update od text edit widgeta. Šele ko jaz recimo povečam okno GUIja (torej nekaj znotraj glavnega threada), se text edit updata z do tedaj zapisano vsebino.

Kakšna ideja kaj delam narobe?

Ja ta mandelbrot sem že dvakrat pregledal pa mi nič ne pomaga.

To, da ne moreš threada pognati pred app.exec() se mi zdi pa malo mimo. Sicer pa glede varnosti ni problema. Tudi ko thread zaključi in pošlje signal GL widgetu je vse ok, samo v text edit ne morem interaktivno pisati iz drugega threada (ga moram v GUI threadu malo požgečkat da pokaže novo vsebino).

Ne, ročno kličem en slot text editorja (insertPlainText(...)). V bistvu mam prevezan cout na ta text editor, tako da lahko rečem cout << "blabla\n" in se bo to izpisalo v editorju. Se pravi da nimam nekega Q objekta, da bi emital signale editorju. In vse dela lepo in prav dokler je izpis v isti niti.

No bom poskusil narediti da bom pošiljal res preko nekega signala, namesto ročnega klicanja slota, čeprav se mi zdi da ne bo pomagalo. Že sedaj se vse izvrši kot bi se moralo, samo sprememba se ne pokaže na zaslonu. No mogoče gre signal preko event loopa GUI threada pa bo zato kaka razlika. Samo se mi pa zdi tole zelo nepotrebna komplikacija.

Mal pozno a vseeno:

c/p iz podanega exampla:

        connect(&thread, SIGNAL(renderedImage(const QImage &, double)),
                this, SLOT(updatePixmap(const QImage &, double)));

Let's start with the connect() call.
Although it looks like a standard signal-slot connection between two QObjects, because the signal is emitted in a different thread than the receiver lives in, the connection is effectively a queued connection. These connections are asynchronous (i.e., non-blocking), meaning that the slot will be called at some point after the emit statement. What's more, the slot will be invoked in the thread in which the receiver lives. Here, the signal is emitted in the worker thread, and the slot is executed in the GUI thread when control returns to the event loop.

Ocitno moras z GUI recmi delat znotraj GUI event loopa (app.exec()). Pa sloti so namenjeni predvsem temu, da jih klices z signali
Kej bolj detaile bi ti mogoce znal BigWhale razlozit. Vsaj obcutek mam, da zna QT dost bolj k jest.