Discussion :

[yan]

Oui, c'est normal. Et le premier point est aussi normal car le thread est un objet et il est assigné au thread d'où il a été créé, d'om le problème pour un slot sur ce second thread. ce cas est explicitement marqué dans la documentation, il me semble.
Si tu veux déplacer un objet dans un autre thread, tu dois le faire explicitement (toujours encore indiqué dans la doc).

J'ai pas dit que c'était pas normal. Au contraire je commence à comprendre pourquoi c'est normal. Je ne pense pas que cela est évident.

Par contre je ne voie en quoi c'est normale : si l'on connect le signal ce même objet vers un objet de la première thread, la connections est non direct. Alors que, du coup, les deux appartienne à la même thread.
Pour ce qui est de la doc, c'est peut être maquer ... Mais j'en suis vraiment pas sur...

[Matthieu Brucher]

C'est à vérifier, je ne pense pas que ce soit le cas, il faut que je regarde le code de plus près.

[yan]

C'est à vérifier, je ne pense pas que ce soit le cas, il faut que je regarde le code de plus près.

dans le main il faut mettre
bool thread_send_signal à true
et utiliser le connect :
QObject::connect(pThread->m_pObj_BeforStart, SIGNAL(mySignal( const myTest & )),pButton , SLOT(mySlot( const myTest & )));

[Matthieu Brucher]

Le thread et le boutton ont été créé par le même thread, donc c'est normal que la connexion soit direct, il me semble

[yan]

Le thread et le boutton ont été créé par le même thread, donc c'est normal que la connexion soit direct, il me semble

oui. On doit pas parlé de la même chose.

avec
bool thread_send_signal = true;
et les deux connect :
QObject::connect(pButton, SIGNAL(mySignal( const myTest & )), pThread->m_pObj_BeforStart, SLOT(mySlot( const myTest & )));
QObject::connect(pThread->m_pObj_BeforStart, SIGNAL(mySignal( const myTest & )),pButton , SLOT(mySlot( const myTest & )));

la première est direct et la second non direct
Alors quel aurait du être direct toutes les deux

[yan]

C'est normal en faite.
La doc dit ca :

Accessing QObject Subclasses from Other Threads

QObject and all of its subclasses are not thread-safe. This includes the entire event delivery system. It is important to keep in mind that the event loop may be delivering events to your QObject subclass while you are accessing the object from another thread.

If you are calling a function on an QObject subclass that doesn't live in the current thread and the object might receive events, you must protect all access to your QObject subclass's internal data with a mutex; otherwise, you may experience crashes or other undesired behavior.

Like other objects, QThread objects live in the thread where the object was created -- not in the thread that is created when QThread::run() is called. It is generally unsafe to provide slots in your QThread subclass, unless you protect the member variables with a mutex.

On the other hand, you can safely emit signals from your QThread::run() implementation, because signal emission is thread-safe.

et dans l'exemple demandelbrot

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

...Faut savoir lire entre les lignes