> 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
> 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 - Thomas ----------------------------------------------------------- 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 > >
