Bug 415019

Summary: Creating a dialog with QFileDialog::setSupportedSchemes({QStringLiteral("file")}); hides all ioslaves, even those that return `file://<something>` string
Product: [Applications] kdialog Reporter: Nate Graham <nate>
Component: generalAssignee: Brad Hards <bradh>
Status: ASSIGNED ---    
Severity: normal CC: bugseforuns, cw, fabian, kde, kdelibs-bugs, kpschoedel, leonny02, meven.car, meven29, sephiroth_pk
Priority: NOR    
Version: 19.11.80   
Target Milestone: ---   
Platform: Other   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=406450
https://bugs.kde.org/show_bug.cgi?id=450476
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Nate Graham 2019-12-10 15:48:22 UTC
Run `kdialog --getsavefilename`. Observe that the Places panel omits all ioslaves. However many ioslaves will return a `file://<something>` string, and those should show up in the dialog.

Creating a file dialog with QFileDialog::setSupportedSchemes({QStringLiteral("file")}); should onlly hide the ioslaves that do not return a `file://<something>` string

Relevant kdialog source code: https://cgit.kde.org/kdialog.git/tree/src/kdialog.cpp#n853
Comment 1 Nate Graham 2019-12-10 15:51:47 UTC
The practical result of this is that desirable ioslaves like recentlyused:/locations are inaccessible in the save dialog created by `kdialog --getsavefilename`, which is used by Chromium and Firefox on Ubuntu and openSUSE to save files.
Comment 2 Nate Graham 2019-12-10 16:23:37 UTC
Looking at this deeper in the relevant KIO code, I'm wondering if we should actually fix this in kdialog. What we're trying to do is exclude network locations so you can't chose one of them as the path, but in so doing, we get rid of all kioslaves. We could just be more selective there instead of doing some super fancy logic to override the result of supportedSchemes() in KIO that may not be appropriate.
Comment 3 Nate Graham 2019-12-10 17:05:04 UTC
Patch: https://phabricator.kde.org/D25856
Comment 4 Nate Graham 2020-06-16 05:33:44 UTC
*** Bug 423017 has been marked as a duplicate of this bug. ***
Comment 5 Nate Graham 2020-06-16 05:34:22 UTC
I gotta redo my patch to fix this properly
Comment 6 Christoph Feck 2020-07-05 13:03:53 UTC
It could show all places and use kio-fuse to return a local path to the requesting application, unless the KIO protocol knows itself how to return a local path, e.g. for trash:// or desktop://
Comment 7 Nate Graham 2021-05-12 16:42:20 UTC
*** Bug 436847 has been marked as a duplicate of this bug. ***
Comment 8 Patrick Silva 2021-05-30 15:55:31 UTC
*** Bug 437465 has been marked as a duplicate of this bug. ***
Comment 9 Nate Graham 2022-03-09 20:26:32 UTC
*** Bug 450476 has been marked as a duplicate of this bug. ***
Comment 10 Méven Car 2022-03-15 08:29:06 UTC
Kioslave have a metadata "Class" field to designate those that depend on local FS.
That should include all those that were added to `schemesthatReturnLocalFiles()` function and more broadly.

Example: https://invent.kde.org/frameworks/kio/-/merge_requests/117

> It could show all places and use kio-fuse to return a local path to the requesting application, unless the KIO protocol knows itself how to return a local path, e.g. for trash:// or desktop://

desktop:/ should be fine, but not trash because it does not support well mostLocalUrl which is used in those cases.

https://invent.kde.org/frameworks/kio/-/merge_requests/618

"--getsavefilename" implies write access though and not all those protocols support writing.