[Qt-interest] QObject::moveToThread: Widgets cannot be moved toa new thread

[Scott Aron Bloom]

From: qt-interest-bounces at trolltech.com
[mailto:qt-interest-bounces at trolltech.com] On Behalf Of Konrad Rosenbaum
Sent: Friday, July 31, 2009 2:07 AM
To: qt-interest at trolltech.com
Subject: Re: [Qt-interest] QObject::moveToThread: Widgets cannot be
moved toa new thread

Hi,

On Friday 31 July 2009, Arnold Krille wrote:
> The technical reason is (as explained at various places in the docs 
> and explained regularly here on the list) that all the gui-interacting

> things have to be done in the main thread (where main-thread is not 
> necessarily the one where main() is executed but the one where 
> QApplication is instantiated). Because at least some of the 
> Qt-supported graphics systems need all the communication to be done by
one thread (X11 for example).

To expand a little bit:

For X11 it is easy to explain: it uses a socket connection between
client (Qt program) and server (X11 graphics system) to transport GUI
commands (like "allocate window", "show window", "draw rectangle"). This
socket must be used synchronously or the bytes of different commands
might get mixed up and X11 would terminate your GUI. In theory it would
be possible to protect that connection with a Mutex, but that would make
Qt much slower.

Other GUI environments require that graphics contexts are used in one
thread exclusively because they have similar synchronicity requirements
(eg. 
access to GUI memory must be synchronous or GUI functions are not
reentrant or thread safe).

As for the GUI-thread-check, it is there, I just found this in the
source of
QWidget:
#ifndef QT_NO_THREAD
    if (!q->parent()) {
        Q_ASSERT_X(q->thread() == qApp->thread(), "QWidget",
                   "Widgets must be created in the GUI thread.");
    }
#endif

I'm not entirely sure why the test is not executed if the widget has a
parent on creation.


	Konrad
-----Original Message-----

I think you will find, there is another check somewhere that prevents an
object from being a parent of an object in another thread...

So if the parent is set, the check is already made.
Scott