I don't think that is true, that would make most applications unusable.

The nested event loop used by QDialog::exec() just filters certain user event intended for the dialog's parent or the whole application (depending on the used modality setting).

Easily testable by having a timer update a label in the dialog's parent.
Not only will the timer event be processed, the label will also receive its paint event.
Hmm, I suppose that's correct. I was thinking mostly in terms of user interaction with the parent and not "background" event processing. I guess I have never programmed a case such as the one you describe.

That implies that a modal QDialog could send signals that would update a progress bar in the parent widget, right?