[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Window modality, (was: Re: KDirWatch bug and the analysis. Help =?iso-8859-1?Q?is_welcome!)?=
From:       Thomas_Lübking <thomas.luebking () gmail ! com>
Date:       2013-08-02 12:47:41
Message-ID: 70b7c930-a901-49c6-9d70-2ca998a34709 () gmail ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]