Handling graphical objects (QWidget objects) in different threads ?

[anupamgee]

Hi

Is is possible to make different threads each handling different gui objects like window containing textedits, buttons etc. ?
Qt documentation for Qthread says: "Note, however, that it is not possible to use any widget classes in the thread." but in that case, can QThread::moveToThread() be of any help ?

just like in some chatting client, I want the main thread to handle main window - contact list etc, and the chatting window is handled by different thread(s) i.e. whenever somebody sends me a text message, the window popping up should pop up in a different thread.


Thanks

[Coises]

You can do the processing (computation, data base lookups, Internet socket access, whatever) in other threads; but actually updating the widgets themselves really does need to be done in the GUI thread. Signals and slots are great for this — do your processing in a QThread and have it signal a slot in the QWidget, which lives in the GUI thread.

Don’t confuse separate windows with separate threads. Each window gets its own messages, but they all still live in the GUI thread. To the best of my knowledge, this is not a limitation of Qt: it is a limitation of virtually all windowing systems currently in use. (You are probably misunderstanding “some chatting client” if you think each window lives in a different thread.) The only way around this would be to spawn a completely new QProcess for each independent top-level window, and it’s unlikely that you’d want to do that, or that it would accomplish anything useful.

[anupamgee]

Thanks for the reply :-)

One more doubt on the same "thread" thing:
what is the use of void QObject::moveToThread(QThread *targetThread) ?

What exactly does moving a QObject to a different thread means ?

[Coises]

What exactly does moving a QObject to a different thread means ?

The thread in which a QObject “lives” is the thread in which events directed to that object are dispatched. For example, when a signal from one thread is connected to a slot of an object in a different thread in the default way (allowing the connection type to default to Qt::AutoConnection (http://doc.trolltech.com/latest/qt.html#ConnectionType-enum)), the signal will be delivered through the event queue of the thread to which the object containing the slot belongs, so that the slot will be executed in the receiving object’s thread (not the signaling thread).

Since an object initially lives in the thread in which its constructor ran, you would commonly call QObject::moveToThread if, after constructing an object in the GUI thread, you wanted signals, timer events, etc. sent to it to execute in some other thread.

As far as I can tell, this is the only practical effect of thread affinity — it determines which thread’s event queue will deliver events to the object.

QThread itself can be confusing; like any other QObject, a QThread object initially lives in the thread that constructed it — not the thread represented by the QThread object, which is the new thread in which QThread::run executes after QThread::start is called. You can, however, move a QThread to itself, so long as you do that from the thread in which it was constructed.