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

[Frank Reininghaus]

Hi,

2013/8/2 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.

sorry for the late response. I did discuss the "KUniqueApplication"
issue with Peter in the mean time. It seems that the "Strigi crashes
all the time" thing was the reason why every window was made to run in
its own process, but I guess that now, a few years later, the
libraries that we use are stable enough, so one could make Dolphin a
KUniqueApplication again.

But still, a reliable solution for the "modal dialog" problem should
be found before, preferably at the places where the dialogs are
created. For example, most of what KIO does is asynchronous, so it's
not even clear if the URL that the dialog (i.e., "File exists"
already") refers to is still open in the view. Therefore, I don't
really see a good reason why such a dialog should be modal at all.

Cheers,
Frank