Review Request 126750: Make KIconDialog and its sub-dialog Qt::WindowModal, rather than Qt::NonModal

[José Millán Soto]

> On Jan. 15, 2016, 7:20 a.m., Martin Gräßlin wrote:
> > > The KIconDialog itself works fine, but the "Browse..." sub dialog, which is a grand child of the modal dialog, is opened in the background and cannot be used
> > 
> > this sounds like a Qt bug or a KFileDialog bug. The sub dialog should set a transient hint and that's respected by the window manager with and without having the modal flag.
> > 
> > My suggestion is that we verify it's a bug, locate it and fix it and don't work around it. To verify that it is a bug: xprop and xwininfo of all three windows are needed.
> 
> Frank Reininghaus wrote:
>     Thanks Martin. I'm not familiar with these window management issues, so your feedback is greatly appreciated. I attached the xprop and xwinfo output for the three windows to the bug report: https://bugs.kde.org/show_bug.cgi?id=355310#c8
>     
>     It would be great if you could take a look.
> 
> Christoph Feck wrote:
>     Martin, does the xinfo attached to the above bug report help to identify the issue?
>     
>     (point Thomas here, if you are lacking time :)
> 
> Martin Gräßlin wrote:
>     sorry, somehow I missed this one :-(
>     
>     The choose icon dialog (0x4c000a9) is a transient for the Add entry dialog (0x4c00020).
>      
>     The file dialog is a transient for a window (0x4c00005) which is not in the output.
>     
>     So something sounds wrong here. If I understand it correctly the file dialog should have been a transient for the choose icon dialog?
> 
> Christoph Feck wrote:
>     If I understand this patch correctly, this is what it tries to fix? It is possible that this would cause blocking in applications (in particular the Plasma shell), so it needs a review from someone who actually runs Plasma 5 and tries it with this patch applied.
> 
> Kai Uwe Broulik wrote:
>     In KDeclarative we have QML bindings for the IconDialog which we use in Plasma and in there we also use WindowModal by default.

> If I understand this patch correctly, this is what it tries to fix? It is possible that this would cause blocking in applications (in particular the Plasma shell), so it needs a review from someone who actually runs Plasma 5 and tries it with this patch applied.

I've just tested Plasma shell with this patch active (Selecting application launcher preferences and launching the browse icon dialog from there) and it does not block the application. It can be used normally. The panel becames grayed however, but it continues working.


- José


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126750/#review91124
-----------------------------------------------------------


On Jan. 14, 2016, 11:36 p.m., Frank Reininghaus wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126750/
> -----------------------------------------------------------
> 
> (Updated Jan. 14, 2016, 11:36 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Bugs: 355310
>     https://bugs.kde.org/show_bug.cgi?id=355310
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> -------
> 
> Currently, KIconDialog::showDialog() sets the modality to Qt::NonModal by calling
> 
> setModal(false);
> 
> I found that this was done in https://quickgit.kde.org/?p=kdelibs.git&a=commit&h=d0d2639c126f88a44c852b738550a9427c6260bb in order to prevent that a modal dialog locks an entire application, such as Plasma.
> 
> Unfortunately, this has an unwanted side effect in the "Places" of Dolphin and the file dialog: the KIconDialog is the child of a modal "Add Places Entry" dialog there. The KIconDialog itself works fine, but the "Browse..." sub dialog, which is a grand child of the modal dialog, is opened in the background and cannot be used (it could be that this worked for some reason in Qt4 times - I guess we would have received bug reports about this issue earlier otherwise).
> 
> This can be fixed by setting the modality to Qt::WindowModal, which ensures that the dialogs block their respective parents (but not the entire application - that would happen if the modality was set to Qt::ApplicationModal, for example by calling setModal(true)).
> 
> Note that there are two setModal(true) calls in the KIconDialog constructors. They have no effect if the dialog is opened with showDialog() (which is what happens if the dialog is opened by clicking a KIconButton) because the modality is overwritten there. I'm not sure though if there are any other uses of KIconDialog which would break if the apparently superfluous calls were removed. This might need further investigation.
> 
> 
> Diffs
> -----
> 
>   src/kicondialog.cpp cca4ed3 
> 
> Diff: https://git.reviewboard.kde.org/r/126750/diff/
> 
> 
> Testing
> -------
> 
> The "Browse..." sub dialog of the icon dialog works fine again in Dolphin and KWrite's file dialog when creating a new "Place".
> 
> I could not test if this affects Plasma somehow because I currently do not have a full self-built Plasma session running. It could probably be checked by opening the "Properties..." of a file in FolderView, clicking the icon, and then opening the "Browse..." sub dialog of the KIconDialog. This should hopefully not lock the entire Plasma session (because the dialogs are window modal, and not application modal). If anyone finds problems with that or has ideas for improvement, please let me know!
> 
> 
> Thanks,
> 
> Frank Reininghaus
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160906/640233b3/attachment-0001.html>