From kfm-devel Fri Aug 02 12:47:41 2013 From: =?iso-8859-1?Q?Thomas_L=FCbking?= Date: Fri, 02 Aug 2013 12:47:41 +0000 To: kfm-devel Subject: Re: Window modality, (was: Re: KDirWatch bug and the analysis. Help =?iso-8859-1?Q?is_welcome!)?= Message-Id: <70b7c930-a901-49c6-9d70-2ca998a34709 () gmail ! com> X-MARC-Message: https://marc.info/?l=kfm-devel&m=137544758530426 On Freitag, 2. August 2013 13:03:44 CEST, Frank Reininghaus wrote:=0A> = If I understand correctly, it's installed if a widget is added=0A> as a= child of the main window, and and widget is not modal yet (maybe=0A> b= ecause the dialog has been constructed, but its exec() function=0A> has= n't been called yet), right?=0A=0AYes, that's pretty much the usual cas= e.=0A=0A> Would setting the modality to Qt::WindowModal fail then becau= se that is=0A> overwritten again once exec() is called, and that is why= you need the event=0A> filter that sets the right modality once the di= alog is shown?=0A=0AYes. Also we don't want to make non-modal windows m= odal, so a broad setWindowModality() would be plain wrong.=0AThe window= already has to be modal and the "correct" moment to check that is when= it's shown.=0A=0AHandling it directly in the childEvent and removing t= he eventfilter is just to avoid eventfiltering and "in the good hope th= at nobody screws around with modality", ie. the modal window could be h= idden, re-modalized and shown again (and since we don't filter that any= more get the "wrong" state) or be re-modalized betwenn childEvent and s= howEvent.=0A=0ASeems insane, but is technically of course possible.=0A=0A= > Moreover, AFAIK we actually set the DolphinView as the parent of KIO'= s=0A> jobs=0AAhh. For deletion and some panel actions, but yes and no -= that does not work.=0AIt has to be like "job->ui()->setWindow(window()= );" (Why would it not?) or the modality fixup has to intercept childEve= nts to those widgets as well.=0A=0ACheers,=0AThomas