From kfm-devel Fri Aug 02 11:03:44 2013 From: Frank Reininghaus Date: Fri, 02 Aug 2013 11:03:44 +0000 To: kfm-devel Subject: Re: Window modality, (was: Re: KDirWatch bug and the analysis. Help is welcome!) Message-Id: X-MARC-Message: https://marc.info/?l=kfm-devel&m=137544144328335 Hi Thomas, 2013/8/1 Thomas L=FCbking: > > *** 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=3D137529683100002&r=3D1&w=3D2 >> http://quickgit.kde.org/?p=3Dkde-baseapps.git&a=3Dcommit&h=3Dfff7573ebb9= 10712ad97951bf1762e6a7bb0bdc7 > > > 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