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

Frank Reininghaus frank78ac at googlemail.com
Fri Aug 2 12:03:44 BST 2013


Hi Thomas,

2013/8/1 Thomas Lübking:
>
>      *** Please keep me CC, thanks ***

Just to give those who are not subscribed to k-c-d a bit of context,
the discussion started here:

http://lists.kde.org/?t=137529683100002&r=1&w=2

>> http://quickgit.kde.org/?p=kde-baseapps.git&a=commit&h=fff7573ebb910712ad97951bf1762e6a7bb0bdc7
>
>
> Thanks. Seems mostly crashing, window modality and status message
> assignment.
>
>> OK, thanks for the hint! Not all modal dialogs come from Dolphin
>> itself though (example: KIO's "File exists already" dialog), so one
>> would have to make sure that these external dialogs use
>> Qt::WindowModal too.
>> ...
>> Well, if it can be done without regressions (except for the "one
>> window crashes all" issue), then I wouldn't mind. It would reduce the
>> memory usage and the startup time, after all.
>
>
> Depends on how "ugly" your willing to let it get. See attached patch.

Thanks for looking into this!

At first sight, it's not quite clear to me why the eventFilter is
needed. 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? 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?

Moreover, AFAIK we actually set the DolphinView as the parent of KIO's
jobs, and thus the DolphinView will be used as the parent of the modal
dialogs as well. Will DolphinMainWindow really receive the childEvents
then?

Cheers,
Frank




More information about the kfm-devel mailing list