Window modality, (was: Re: KDirWatch bug and the analysis. Help is welcome!)

[Thomas Lübking]

On Freitag, 2. August 2013 13:03:44 CEST, Frank Reininghaus wrote:
> If I understand correctly, it's installed if a widget is added
> as a child of the main window, and and widget is not modal yet (maybe
> because the dialog has been constructed, but its exec() function
> hasn't been called yet), right?

Yes, that's pretty much the usual case.

> Would setting the modality to Qt::WindowModal fail then because that is
> overwritten again once exec() is called, and that is why you need the event
> filter that sets the right modality once the dialog is shown?

Yes. Also we don't want to make non-modal windows modal, so a broad setWindowModality() would be plain wrong.
The window already has to be modal and the "correct" moment to check that is when it's shown.

Handling it directly in the childEvent and removing the eventfilter is just to avoid eventfiltering and "in the good hope that nobody screws around with modality", ie. the modal window could be hidden, re-modalized and shown again (and since we don't filter that anymore get the "wrong" state) or be re-modalized betwenn childEvent and showEvent.

Seems insane, but is technically of course possible.

> Moreover, AFAIK we actually set the DolphinView as the parent of KIO's
> jobs
Ahh. For deletion and some panel actions, but yes and no - that does not work.
It has to be like "job->ui()->setWindow(window());" (Why would it not?) or the modality fixup has to intercept childEvents to those widgets as well.

Cheers,
Thomas