Let's say you use Dolphin to navigate to a Samba share, NFS location, FTP server, or Google Drive. All is well so far. You use Dolphin to open a file there in a non-KIO-using app like LibreOffice Writer, Inkscape, or Blender. All is well. You change the file and save it. KIO displays a dialog asking you whether you want to re-upload the changed file to the server, which is a bit annoying (see Bug 398216), but it works. There is a problem, though: The non-KIO-using app's non-KDE file picker cannot see the remote location. This means that you cannot use File > Open... to open new documents on the remote location, nor can you use File > Save As... to save a copy of the document to the remote location using. There is probably nothing we can do about this short of secretly mounting the remote location using FUSE like GNOME's GVFS does (See bug 75324) and exposing the mount to the GNOME open/save dialogs, but I'm filing this bug anyway just in case anyone can think of something clever we can do anyway.
Git commit fcf4529f62e15cfc891757cf372c4ef7ee7ea4d1 by Alexander Saoutkin. Committed on 02/01/2020 at 18:29. Pushed by asaoutkin into branch 'master'. Adding support for mounting KIOFuse URLs for applications that don't use KIO Summary: This patch is required to provide seamless integration with KIOFuse and KIO. The patch attempts to convert URLs that applications will not understand natively into local paths based on a KIOFuse mount. If successful, the URL passed to the application is changed to its location within the KIOFuse mount. If it is not successful, the URL is not changed. If KIOFuse is not installed, then kioexec is simply used. Related: bug 75324, bug 398216, bug 330192 FIXED-IN: 5.66 Test Plan: Compile KIO with this patch. Build and install KIOFuse (follow instructions in README): https://invent.kde.org/kde/kio-fuse Once KIO is built, Dolphin is built with this newly built KIO, and kio-fuse is built, one should start the kio-fuse process. The easiest way to test this is via Dolphin (that is built with this patch): `dbus-launch dolphin`. Once you have done the above one can simply browse to any non-local location in say, Dolphin, where upon opening a URL in a non-KIO enabled app, it should open in the KIOFuse mount, except for MTP/Gdrive URLs - those will use KIOExec. Conversely, KIO URLs in KIO-enabled apps should not use KIOFuse. Reviewers: fvogt, davidedmundson, dfaure, ngraham Reviewed By: dfaure, ngraham Subscribers: alexde, broulik, sitter, davidedmundson, kde-frameworks-devel, ngraham Tags: #frameworks Differential Revision: https://phabricator.kde.org/D23384 M +1 -0 src/core/CMakeLists.txt M +45 -12 src/core/desktopexecparser.cpp A +9 -0 src/core/org.kde.KIOFuse.VFS.xml https://commits.kde.org/kio/fcf4529f62e15cfc891757cf372c4ef7ee7ea4d1
I wonder if this will require changes to GTK.
Hopefully in this case if the file opens in a KIOFuse mount they'll simply use the "save" functionality and hence won't run into this at all. If they choose to use "Save As" hopefully the dialog is smart enough to choose where the current file is currently saved (i.e. in the KIOFuse mount somewhere). If not, I guess they're on their own. However, for dialogs that do exhibit this behaviour, I don't think we want to put up a patch upstream displaying the KIOFuse mount as a location, it'll be better if we patched it such that the behaviour in my paragraph above occurs, thoughts?
(In reply to a.saoutkin from comment #3) > Hopefully in this case if the file opens in a KIOFuse mount they'll simply > use the "save" functionality and hence won't run into this at all. If they > choose to use "Save As" hopefully the dialog is smart enough to choose where > the current file is currently saved (i.e. in the KIOFuse mount somewhere). Generally this is true. > If not, I guess they're on their own. However, for dialogs that do exhibit > this behaviour, I don't think we want to put up a patch upstream displaying > the KIOFuse mount as a location, it'll be better if we patched it such that > the behaviour in my paragraph above occurs, thoughts? Yes, in the cases where the above doesn't work, it should be fixed. However what happens if, in the above use case, the user navigates somewhere else and realizes they need to get back to the FUSE mount location? They can use the back button, but having it visible in the Places panel too would be a nice touch IMO.
I'm not entirely sure how much better that would be. They would then have to navigate all the way back to what they want. Usually a CIFS mount will be tied to just one share. But to get to a KIOFuse samba share, for example, the path would be / -> smb -> user@server -> (insert share folders and files here). Itself, / might do a dirlist with all sorts of slaves already mounted (mtp, sftp, smb, fish etc...), potentially confusing the user. More importantly , where would the patches be though. Do you only want them in KDE dialogs? Do we want GTK dialogs to display them. I know many apps that do their own thing altogether... Do you want each individual mount point in KIOFuse to show up as a separate item, or just the slave? One must also consider performance considerations. With the way the current KIO integration is done, the capability of KIO to cause blocking issues is reduced as much as can be. Even introducing KIOFuse into the places panel I believe can cause issues if it lags hard or deadlocks. In a typical scenario of opening files via Dolphin the only extra command needed is a KIO::stat -> KIO::get. We try to limit browsing inside a mount as much as possible. Allowing an easy way to do so can cause all sorts of issues. Some slaves have a substandard KIO::listDir implementation (MTP being an obvious culprit), and God forbid a user enables previews in a KIOFuse mount. One workaround I can think of, at least in open/save dialogs, is to force redirect to the remote URL if a KIOFuse mount is entered (as is done in https://phabricator.kde.org/D28290).
GTK dialogs already display FUSE mounts mounted by gfvs, just like Nautilus does. I was just thinking we should do the same thing, really. But I see your point that it isn't really needed for the Save case. However it is definitely needed for the Open case, for reasons described in the original bug report.
It sounds like one unfortunate effect of this will be an inability for browsers like Firefox to directly save downloads to the smb share.
(In reply to Kyle Tirak from comment #7) > It sounds like one unfortunate effect of this will be an inability for > browsers like Firefox to directly save downloads to the smb share. With firefox you can use gtk_use_portal option or use firefox from opensuse. In both cases - you got kde file dialogs/