Bug 409551 - Can't interact with modal dialog's parent window which in some cases is a minor usability issue
Summary: Can't interact with modal dialog's parent window which in some cases is a min...
Status: RESOLVED UPSTREAM
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR minor
Target Milestone: ---
Assignee: David Faure
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2019-07-06 12:21 UTC by avlas
Modified: 2020-09-08 22:40 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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!