Bug 415019 - Creating a dialog with QFileDialog::setSupportedSchemes({QStringLiteral("file")}); hides all ioslaves, even those that return `file://<something>` string
Summary: Creating a dialog with QFileDialog::setSupportedSchemes({QStringLiteral("file...
Status: ASSIGNED
Alias: None
Product: kdialog
Classification: Applications
Component: general (show other bugs)
Version: 19.11.80
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Brad Hards
URL:
Keywords:
: 423017 436847 437465 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-12-10 15:48 UTC by Nate Graham
Modified: 2023-05-08 18:27 UTC (History)
10 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 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.