Bug 409551

Summary:	Can't interact with modal dialog's parent window which in some cases is a minor usability issue
Product:	[Plasma] kwin	Reporter:	avlas <jsardid>
Component:	general	Assignee:	David Faure <faure>
Status:	RESOLVED UPSTREAM
Severity:	minor	CC:	aacid, kdelibs-bugs-null, m.weghorn, nate
Priority:	NOR	Keywords:	usability
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description avlas 2019-07-06 12:21:13 UTC

Let me give a bit of context on the use case.

For research I frequently open PDF articles from the browser, take a look to them and decide (or not) saving them for further reading and/or later consultation and reference. Near 100% of the times that decision happens when I am not at page 1, so details of authors and title are not accessible (information I need to organize the bunch of PDFs I have).

Therefore I need to close the Save/Save As dialog opened by intuition, go back to page 1, and proceed to save (again). If this would happen once, I would not care, but when this happens tens of times every day, it feels a bit unpleasant and breaks the flow.

I am not sure about the technicalities, but I think this could be solved if the "Save/Save As" dialog would be in its own process, so even if open, I would still be able to scroll up the main window that appears behind.

This is how it works in PDFs opened in the embedded viewer in Chromium for instance, and that is the feature request here. 

This may be a bug against kio instead of okular, not sure.

Perhaps other use cases (other applications such as Kate, and other dialogs such as Open) might also benefit from this feature as well if extended to them.

Comment 1 2wxsy58236r3 2019-07-06 12:53:23 UTC

I can confirm that this bug also affects other applications such as KWrite.

Comment 2 Michael Weghorn 2019-07-06 12:57:35 UTC

As far as I understand, this would require the Qt file dialog to be non-modal here.
Don't know whether that's easily possible, but even if it was, I see this issue: Okular can not only show but also edit documents (e.g. insert annotations into PDF documents). If the user could interact with the document and edit it while the save dialog is open, what version of the document would be saved?

I'm currently not aware of any program/editor that does have a non-modal save dialog (at least kate, gedit, libreoffice also have modal ones).

Comment 3 avlas 2019-07-06 16:26:29 UTC

(In reply to Michael Weghorn from comment #2)
> As far as I understand, this would require the Qt file dialog to be
> non-modal here.
> Don't know whether that's easily possible, but even if it was, I see this
> issue: Okular can not only show but also edit documents (e.g. insert
> annotations into PDF documents). If the user could interact with the
> document and edit it while the save dialog is open, what version of the
> document would be saved?
> 
> I'm currently not aware of any program/editor that does have a non-modal
> save dialog (at least kate, gedit, libreoffice also have modal ones).

Not sure I understand. I don't see much of a problem, in other words, where the conflict is. Opening a dialog makes no action, right? The action occurs when the button (e.g. save) is clicked and this cannot happen at once with another action, can it?

Comment 4 Michael Weghorn 2019-07-06 20:54:36 UTC

(In reply to avlas from comment #3)
> Not sure I understand. I don't see much of a problem, in other words, where
> the conflict is. Opening a dialog makes no action, right? The action occurs
> when the button (e.g. save) is clicked and this cannot happen at once with
> another action, can it?

I guess you're right (clicking the "Save" button should trigger the QFileDialog::fileSelected signal), at least if one can assume that edit actions aren't long-running, e.g. you click a button and it takes several seconds until the action is completed (which may not be an issue, and could probably still be dealt with by using proper synchronisation between the processes...).

Comment 5 Nate Graham 2020-09-08 15:12:46 UTC

I guess a less invasive solution than the one proposed would be to allow scrolling in the parent window even when a modal dialog is covering it. Would that help?

Comment 6 avlas 2020-09-08 15:19:09 UTC

(In reply to Nate Graham from comment #5)
> I guess a less invasive solution than the one proposed would be to allow
> scrolling in the parent window even when a modal dialog is covering it.
> Would that help?

I think it would!

Comment 7 Christoph Feck 2020-09-08 22:11:36 UTC

Not sure if I understand this ticket correctly, but modality (i.e. windows which block input) is decided in the Qt library, so this tickets is probably assigned wrongly.

Comment 8 Nate Graham 2020-09-08 22:40:04 UTC

Yeah, that's true. You'll need to file a Qt bug at https://bugreports.qt.io/ I guess. Once you do, please put the URL for it in the URL field of this bug report. Thanks!