[Qt-interest] Trying to understand Signal/slots.

[Thiago Macieira]

On Saturday 21. August 2010 17.25.55 phil prentice wrote:
> If I open a modeless dialog in one of my application windows I would have
> half  expected that any new openVIwindow signals would not be serviced
> until the modeless dialog returned so freeing up the event loop of the
> main application?

If you're showing a dialog, the event loop is being run. That's how events 
from the system are received and processed.

This includes events carrying queued signal emissions.

If you want such signals not to be serviced, you need to write such code 
yourself.

> I assume that the emit signal would have caused a queued signal to be sent
> to  the main application because its being sent from a different
> thread?  Is this assumption where I've got it wrong?

No. That assumption is correct.

Your went wrong when you assumed that showing a dialog blocked the event loop.

> Is what I am doing wrong the fact that m_iconThread object was created in
> the  same thread as the applications so regardless of which thread is
> doing the emitting, the slot is being called directly and so the actual
> run thread is creating the new window itself directly.....which I assume
> is a BIG NO-NO?

The thread the signal emitter belongs to is irrelevant. You're right in the 
fact that the m_iconThread object belongs to its creating thread, not to the 
thread that it started.

But a connection is queued if the target object's thread is not the same as 
the current thread. When the signal is emitted from run(), it becomes queued 
and is posted via an event from that thread into the main thread.

Emitting signals from classes derived from QThread is ok. The big NO-NO is the 
use of slots in such classes (see the "You're doing it wrong" blog).

> I am very happy with the way the application is working at the moment, but
> I  just think that I'm just doing it wrong?? And I will probably get
> problems later???

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20100821/9dcbd3f8/attachment.bin