[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Review Request 114436: Set WindowModality of all KIO message box to Qt::WindowModal
From: "Dawit Alemayehu" <adawit () kde ! org>
Date: 2013-12-18 6:12:27
Message-ID: 20131218061227.5918.43864 () vidsolbach ! de
[Download RAW message or body]
> On Dec. 13, 2013, 2:27 p.m., Frank Reininghaus wrote:
> > Thanks for looking into this, Dawit! I greatly appreciate this effort.
> >
> >
> > Two questions come to my mind:
> >
> > 1. Why should these dialogs be modal at all? Everything that KIO does is \
> > asynchronous, so it could very well be that the window isn't even showing the \
> > directory (where the action took place that triggered the dialog) any more.
> > 2. Since every little change can have unexpected side effects, and the "modality" \
> > issue is not causing a lot of trouble for users right now (please correct me if \
> > I'm wrong), maybe this change should better be done in master? Currently, the \
> > only situation in which a single process can have multiple windows that can \
> > perform file management actions is that there are two Konqueror windows, one of \
> > which was opened from the other one with "Open New Window", I think (but I might \
> > be overlooking some other possibilities).
> >
> > Some background for people who have not followed the "modality" discussion in the \
> > past: some time ago, Thomas raised the question why Dolphin is not a \
> > KUniqueApplication any more. This was done mostly because Strigi made Dolphin \
> > crash a lot, and it was quite annoying for users to see all their Dolphin windows \
> > disappear if one of them crashed (this is not a big problem any more), but also \
> > because it was a bit irritating that KIO dialogs would freeze all Dolphin \
> > windows. Some more information can be found in these threads:
> > http://lists.kde.org/?t=137529683100002&r=1&w=2
> > http://lists.kde.org/?t=137537235900004&r=1&w=2
>
> Thomas Lübking wrote:
> > 1. Why should these dialogs be modal at all?
>
> Unless anybody has a better explanation I assume it was done because of either
> a) the wrong assumption that "modal" equals "transient"
> b) the assumption of (a) actually may hold on some systems?
>
> A modal window is used if sequential action is mandatory, eg. if you open a file \
> you can not edit it before you opened it - the modal dialog makes sense to enforce \
> the workflow and assert() it in the code.
> This is obviously not the case here:
> the system MUST be prepared to filesystem changes during the nested eventloop of \
> the modal dilaog, eg. while the dialog asks "do you really want to delete \
> foo/bar.txt" this could just happen in another dolphin window, in konsole, VT1 or \
> through a script or cron job.
>
> On top of this, I do not even think the dialog should be transient.
>
> Eg. I often start a longer (network, crap USB stick) copy job and close dolphin \
> immediately. Popping up questions (override) arrive for the copy job and not the \
> causing process (long closed dolphin)
> The user must get aware that this action is currently halted and requires \
> interaction to continue, but that isn't related to a particular other window. Some \
> "system interaction spot" would be nice but it had to significantly differ from the \
> common "i don't care" notification that pops up because phonon thinks it lost a \
> resource or so. Alternatively the process indicator in the notification area could \
> just start blinking or show a "interaction required!" message/icon/whatsoever.
> This is however probably beyond KDE4.
>
> The fallback (non-plasma context) solution could simply be a "keep above on all \
> desktops" dialog (it doesn't have to get the focus, but must show up visible) what \
> might be a usable approach even for KDE4
> Kai Uwe Broulik wrote:
> Unfortunately that [1] never made it to a final state :-/
>
> [1] http://en.munknex.net/2012/06/new-kde-copy-dialog-first-preview.html
>
> Dawit Alemayehu wrote:
> > 1. Why should these dialogs be modal at all? Everything that KIO does is \
> > asynchronous, so it could very well be that the window isn't even showing the \
> > directory (where the action took place that triggered the dialog) any more.
>
> Which dialogs? There are dialogs requested by the jobs and those that originate \
> from the ioslaves themselves. The prompts from the jobs and ioslaves are distinctly \
> different and cannot be lumped together.
> Though I am not the original creator of these dialogs, I can think of at least one \
> reason why it might have been done this way. Making the dialogs modal is the \
> simplest way to avoid the problem of multiple "File Already Exists" dialog boxes \
> from popping up when copying/moving several files and more than one of those files \
> exist in the destination. Another reason is the jobs themselves might not \
> originally have been written in such a way that they are capable of accommodating \
> asynch responses from prompts.
> As far as prompts from the ioslaves, the user almost always needs to respond to \
> them in order for the ioslaves to proceed. Almost all are mandatory prompts. For \
> example, when a user visits a site and gets prompted with untrusted SSL certificate \
> warning dialog, that prompt needs to be answered before the site will load. It \
> makes no sense to make such prompts non-modal! Otherwise, the user can do whatever \
> including going to a new site by entering another address in the address bar. If \
> the user then goes back and chose to accept the untrusted SSL certificate the \
> browser will to go back to the previous URL.
> > 2. Since every little change can have unexpected side effects, and the "modality" \
> > issue is not causing a lot of trouble for users right now please correct me if \
> > I'm wrong), maybe this change should better be done in master? Currently, the \
> > only situation in which a single process can have multiple windows that can \
> > perform file management actions is that there are two Konqueror windows, one of \
> > which was opened from the other one with "Open New Window", I think (but I might \
> > be overlooking some other possibilities).
>
> Well I have no particular preference to what branch the patch is applied. I just \
> did not see a problem with applying it to the current stable branch because the \
> issue is actually a bug and the change itself does not get rid of modality. It \
> simply restricts it to a given window.
>
> Frank Reininghaus wrote:
> You are right - I was mostly referring to the dialogs of the "File exists already" \
> type. If some user input is needed to load a URL, it probably makes sense to notify \
> the user with a modal dialog.
> BTW, I think the 'multiple "File Already Exists" dialogs' issue already exists - \
> you can easily get them if you move a file to another location from multiple \
> Konqueror/Dolphin windows.
That is because of Dolphin's call to KonqOperations::doDrop sets the parent parameter \
to NULL. That means none of the KIO dialogs will be associated with any window at \
all:
konqueror(12927)/libkonq KonqOperations::doDrop: dest: \
KUrl("file:///home/dalemayehu/Downloads") ,parent: QObject(0x0)
Otherwise, the modal dialog that will be created would have blocked the destination \
window.
- Dawit
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/114436/#review45646
-----------------------------------------------------------
On Dec. 13, 2013, 1:53 p.m., Dawit Alemayehu wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/114436/
> -----------------------------------------------------------
>
> (Updated Dec. 13, 2013, 1:53 p.m.)
>
>
> Review request for kdelibs, David Faure and Frank Reininghaus.
>
>
> Repository: kdelibs
>
>
> Description
> -------
>
> The attached patch changes the WindowModality of all the message/information boxes \
> displayed by KIO::JobUiDelegate to Qt::WindowModal instead of Qt::ApplicationModal. \
> This prevents a message box in one window from blocking all other windows.
>
> Diffs
> -----
>
> kio/kio/jobuidelegate.cpp 8534863
>
> Diff: http://git.reviewboard.kde.org/r/114436/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Dawit Alemayehu
>
>
[Attachment #3 (text/html)]
<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 \
solid;"> <tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://git.reviewboard.kde.org/r/114436/">http://git.reviewboard.kde.org/r/114436/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <p style="margin-top: 0;">On December 13th, 2013, 2:27 p.m. UTC, <b>Frank \
Reininghaus</b> wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px \
solid #d0d0d0; padding-left: 10px;"> <pre style="white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">Thanks for looking into this, Dawit! I greatly appreciate this effort.
Two questions come to my mind:
1. Why should these dialogs be modal at all? Everything that KIO does is \
asynchronous, so it could very well be that the window isn't even showing the \
directory (where the action took place that triggered the dialog) any more.
2. Since every little change can have unexpected side effects, and the \
"modality" issue is not causing a lot of trouble for users right now \
(please correct me if I'm wrong), maybe this change should better be done in \
master? Currently, the only situation in which a single process can have multiple \
windows that can perform file management actions is that there are two Konqueror \
windows, one of which was opened from the other one with "Open New Window", \
I think (but I might be overlooking some other possibilities).
Some background for people who have not followed the "modality" discussion \
in the past: some time ago, Thomas raised the question why Dolphin is not a \
KUniqueApplication any more. This was done mostly because Strigi made Dolphin crash a \
lot, and it was quite annoying for users to see all their Dolphin windows disappear \
if one of them crashed (this is not a big problem any more), but also because it was \
a bit irritating that KIO dialogs would freeze all Dolphin windows. Some more \
information can be found in these threads:
http://lists.kde.org/?t=137529683100002&r=1&w=2
http://lists.kde.org/?t=137537235900004&r=1&w=2</pre>
</blockquote>
<p>On December 13th, 2013, 3:34 p.m. UTC, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">> 1. Why should these \
dialogs be modal at all?
Unless anybody has a better explanation I assume it was done because of either
a) the wrong assumption that "modal" equals "transient"
b) the assumption of (a) actually may hold on some systems?
A modal window is used if sequential action is mandatory, eg. if you open a file you \
can not edit it before you opened it - the modal dialog makes sense to enforce the \
workflow and assert() it in the code.
This is obviously not the case here:
the system MUST be prepared to filesystem changes during the nested eventloop of the \
modal dilaog, eg. while the dialog asks "do you really want to delete \
foo/bar.txt" this could just happen in another dolphin window, in konsole, VT1 \
or through a script or cron job.
On top of this, I do not even think the dialog should be transient.
Eg. I often start a longer (network, crap USB stick) copy job and close dolphin \
immediately. Popping up questions (override) arrive for the copy job and not the \
causing process (long closed dolphin)
The user must get aware that this action is currently halted and requires interaction \
to continue, but that isn't related to a particular other window. Some \
"system interaction spot" would be nice but it had to significantly differ \
from the common "i don't care" notification that pops up because phonon \
thinks it lost a resource or so. Alternatively the process indicator in the \
notification area could just start blinking or show a "interaction \
required!" message/icon/whatsoever.
This is however probably beyond KDE4.
The fallback (non-plasma context) solution could simply be a "keep above on all \
desktops" dialog (it doesn't have to get the focus, but must show up \
visible) what might be a usable approach even for KDE4</pre> </blockquote>
<p>On December 13th, 2013, 3:44 p.m. UTC, <b>Kai Uwe Broulik</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Unfortunately that [1] \
never made it to a final state :-/
[1] http://en.munknex.net/2012/06/new-kde-copy-dialog-first-preview.html</pre>
</blockquote>
<p>On December 14th, 2013, 11:05 p.m. UTC, <b>Dawit Alemayehu</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">> 1. Why should these \
dialogs be modal at all? Everything that KIO does is asynchronous, so it could very \
well be that the window isn't even > showing the directory (where the action \
took place that triggered the dialog) any more.
Which dialogs? There are dialogs requested by the jobs and those that originate from \
the ioslaves themselves. The prompts from the jobs and ioslaves are distinctly \
different and cannot be lumped together.
Though I am not the original creator of these dialogs, I can think of at least one \
reason why it might have been done this way. Making the dialogs modal is the simplest \
way to avoid the problem of multiple "File Already Exists" dialog boxes \
from popping up when copying/moving several files and more than one of those files \
exist in the destination. Another reason is the jobs themselves might not originally \
have been written in such a way that they are capable of accommodating asynch \
responses from prompts.
As far as prompts from the ioslaves, the user almost always needs to respond to them \
in order for the ioslaves to proceed. Almost all are mandatory prompts. For example, \
when a user visits a site and gets prompted with untrusted SSL certificate warning \
dialog, that prompt needs to be answered before the site will load. It makes no sense \
to make such prompts non-modal! Otherwise, the user can do whatever including going \
to a new site by entering another address in the address bar. If the user then goes \
back and chose to accept the untrusted SSL certificate the browser will to go back to \
the previous URL.
> 2. Since every little change can have unexpected side effects, and the \
"modality" issue is not causing a lot of trouble for users right now > \
please correct me if I'm wrong), maybe this change should better be done in \
master? Currently, the only situation in which a single process > can have \
multiple windows that can perform file management actions is that there are two \
Konqueror windows, one of which was opened from the > other one with "Open \
New Window", I think (but I might be overlooking some other possibilities).
Well I have no particular preference to what branch the patch is applied. I just did \
not see a problem with applying it to the current stable branch because the issue is \
actually a bug and the change itself does not get rid of modality. It simply \
restricts it to a given window. </pre>
</blockquote>
<p>On December 17th, 2013, 10:06 a.m. UTC, <b>Frank Reininghaus</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">You are right - I was \
mostly referring to the dialogs of the "File exists already" type. If some \
user input is needed to load a URL, it probably makes sense to notify the user with a \
modal dialog.
BTW, I think the 'multiple "File Already Exists" dialogs' issue \
already exists - you can easily get them if you move a file to another location from \
multiple Konqueror/Dolphin windows.</pre> </blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">That is because of \
Dolphin's call to KonqOperations::doDrop sets the parent parameter to NULL. That \
means none of the KIO dialogs will be associated with any window at all:
konqueror(12927)/libkonq KonqOperations::doDrop: dest: \
KUrl("file:///home/dalemayehu/Downloads") ,parent: QObject(0x0)
Otherwise, the modal dialog that will be created would have blocked the destination \
window.</pre> <br />
<p>- Dawit</p>
<br />
<p>On December 13th, 2013, 1:53 p.m. UTC, Dawit Alemayehu wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" \
style="background-image: \
url('http://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); \
background-position: left top; background-repeat: repeat-x; border: 1px black \
solid;"> <tr>
<td>
<div>Review request for kdelibs, David Faure and Frank Reininghaus.</div>
<div>By Dawit Alemayehu.</div>
<p style="color: grey;"><i>Updated Dec. 13, 2013, 1:53 p.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kdelibs
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" \
style="border: 1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">The attached patch changes the WindowModality of all the \
message/information boxes displayed by KIO::JobUiDelegate to Qt::WindowModal instead \
of Qt::ApplicationModal. This prevents a message box in one window from blocking all \
other windows.</pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>kio/kio/jobuidelegate.cpp <span style="color: grey">(8534863)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/114436/diff/" style="margin-left: \
3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic