If I access a remote smb share with dolphin, I can drag and drop a text file on an open kate to open the text file. This seems to be about the only app it works with. Even KDE apps I've tried don't work. What I know doesn't work: - Thunderbird e-mail attaching - videos with kdenlive - pictures with krita - Audio files with audacity - text and source files with vscode Seems like if an icon is dragged/dropped to an app, it should send the app the local path (if one is available).
KDE apps don't use kio-fuse (they don't need to) so drag-and-drop failures between KDE apps are unrelated. You would want to file bugs on the apps you're dragging the file to. However drag-and-drop failures from KDE apps to 3rd-party, non-KIO-using apps would indeed require kio-fuse. A new feature would need to be implemented to handle it. Implementing this would entail something intercepting the drag, inspecting its contents, and if the contents are a URL and the destination does not support a URL with the scheme of the drag's URL, something would mount the location using kio-fuse (if needed) and rewrite the URL to be the file path for the file on the FUSE mount. On X11, the only "something" that could do this is the X11 server, which is either feature frozen or abandoned, depending on your point of view. As a result, support for this on X11 is probably impossible, sadly. However it's a possibility on Wayland, where the compositor (KWin) can be that "something". It knows about paste data, it knows the destination, and it can be taught how to use kio-fuse.
Why not just use the fuse path for everything smb related, if fuse is supported on the host system?
Then we break apps that do support and expect smb:// URLs, which would include not only all KDE apps, but also some 3rd-party ones that can be configured with internal Samba clients, such as VLC.
Sorry. I know you shouldn't have to educate me, but if all those apps can take file paths, how do they break? Even with VLC accepting smb:// urls doesn't that cause problems when the share it's trying to access is password protected? Sure kio may auth the share, but then it passes the url to vnc and vnc needs to authenticate. In fact, to get around that, I've set vlc to use the file path %F, rather than the %U url to get around that, and it works better than passing the smb://, IMO.
s/vnc/vlc
The gist of your question is "why don't we always use kio-fuse and local paths instead of sometimes using native KIO stuff with URLs?". The answer is because native KIO operations are faster and asynchronous. They are guaranteed to never block the GUI, which FUSE mounts can do. It's not common, but it's possible. And the extra FUSE layer imposes a performance penalty. FWIW GNOME uses this same architecture: their GIO library (a rough KIO equivalent) passes URLs to GIO-using apps in an asynchronous fashion, but falls back to local FUSE paths provided by gvfs for non-GIO-using apps.
Okay, thanks for that explanation. So, should we file reports when we find apps that don't work with opening (double or right click), and drag and drop, or not? I'm certainly glad that the changes we've seen in the last year on this have taken place. It has made things so much nicer working with remote shares and KDE. For now, what I end up doing is hitting F4 to open a shell in dolphin, pwd to get the location to the fuse mount, paste that to dolphin and use that for drag and drop operations. It's a bit of a kludge, but a lot better than it was prior to kio-fuse integration.
(In reply to Jason Straight from comment #7) > Okay, thanks for that explanation. So, should we file reports when we find > apps that don't work with opening (double or right click), and drag and > drop, or not? Yes please. drag-and-drop bugs for KDE apps should generally be filed on the app itself as typically the app is responsible for handling drags. Likewise, bugs with apps not opening files on click/double-click/right-click should be filed on the app. kio-fuse is not involved in any of these use cases. > I'm certainly glad that the changes we've seen in the last year on this have > taken place. It has made things so much nicer working with remote shares and > KDE. Great!
(In reply to Nate Graham from comment #6) Reading the GIO docs (https://wiki.gnome.org/Projects/gvfs/doc): > The g_file_get_path() method as implemented in GDaemonFile can provide local pathname when FUSE mountpoint is registered and connected with the master gvfs daemon. This path can then be easily used for spawning applications with a local path. When application is asked to create new GFile instance using the local FUSE path, it is automatically converted to a native URI. That way we don't need to pass URI strings outside of GIO world. Is it feasible to do this? Only pass around FUSE paths for compatibility but having KIO convert them to KIO-native URIs in KDE apps?
(In reply to Bharadwaj Raju from comment #9) > (In reply to Nate Graham from comment #6) > > Reading the GIO docs (https://wiki.gnome.org/Projects/gvfs/doc): > > > The g_file_get_path() method as implemented in GDaemonFile can provide local pathname when FUSE mountpoint is registered and connected with the master gvfs daemon. This path can then be easily used for spawning applications with a local path. When application is asked to create new GFile instance using the local FUSE path, it is automatically converted to a native URI. That way we don't need to pass URI strings outside of GIO world. > > Is it feasible to do this? Only pass around FUSE paths for compatibility but > having KIO convert them to KIO-native URIs in KDE apps? That's exactly what I hand in mind from the beginning, no idea that GIO does that as well. There are some more tricks which could be done, like including the KIO URL as a different mimetype in the DnD data, in addition to the local fuse path as main URL (text/uri-list).
Just got bit by this with Dolphin+SMB and MPV. Neither Open With or drag and drop work, presumably because mpv tries to use smb://. Is there some workaround available right now that would make this work seamlessly for all applications? Having a system option to always use kio-fuse would be one way of doing it, but it is still not a good default user experience. For reporting bugs upstream to specific apps, what would be the way to describe what exactly needs to be done?
(In reply to Fabian Vogt from comment #10) > (In reply to Bharadwaj Raju from comment #9) > > (In reply to Nate Graham from comment #6) > > > > Reading the GIO docs (https://wiki.gnome.org/Projects/gvfs/doc): > > > > > The g_file_get_path() method as implemented in GDaemonFile can provide local pathname when FUSE mountpoint is registered and connected with the master gvfs daemon. This path can then be easily used for spawning applications with a local path. When application is asked to create new GFile instance using the local FUSE path, it is automatically converted to a native URI. That way we don't need to pass URI strings outside of GIO world. > > > > Is it feasible to do this? Only pass around FUSE paths for compatibility but > > having KIO convert them to KIO-native URIs in KDE apps? > > ... > > There are some more tricks which could be done, like including the KIO URL > as a different mimetype in the DnD data, in addition to the local fuse path > as main URL (text/uri-list). This sounds like an elegant solution. It provides a default behaviour that "just works" for any application out of the box, but then allows the native KDE apps to add value by transparently using a more efficient mechanism (kio). I don't know if the use of kio-fuse would introduce any surprises for users. Examples would be strange "/run/<uid>/..." pathnames appearing in file pickers, or additional prompts for usernames and passwords. Ideally the latter should only happen once and the data be saved for future accesses of the same resource. Improving the user experience must surely be the primary goal. It's more than a bit disappointing that seamless drag+drop for the filesystem types the OS can support isn't present by default.
> For now, what I end up doing is hitting F4 to open a shell in dolphin, pwd > to get the location to the fuse mount, paste that to dolphin and use that > for drag and drop operations. It's a bit of a kludge, but a lot better than > it was prior to kio-fuse integration. Interesting. I'm on KDE Neon 6.3. For me, on an "out of the box" desktop- * The "Open Terminal" shortcut in Dolphin is alt-F4, not F4 * Open Terminal opens a terminal in $HOME, not `pwd`, so it doesn't help find the underlying path * I see no evidence in `findmnt` of Dolphin creating fuse mounts. It looks as if Dolphin browses SMB shares internally and isn't creating a kio-fuse mount
UPDATE I discovered the Terminal pane in Dolphin (new KDE user) and having enabled this once from the menu, (a) F4 is now working; and (b) the fuse path to the directory is shown in the prompt. So, shrink the Terminal pane down to one line and you have a basic "current mounted path" watcher.
> Only pass around FUSE paths for compatibility but having KIO convert them to KIO-native URIs in KDE apps? Unless I'm missing something, the various KIO Job classes just accept QUrls... there's no place where we could intercept and translate them centrally, is there? > There are some more tricks which could be done, like including the KIO URL as a different mimetype in the DnD data, in addition to the local fuse path as main URL (text/uri-list). This is starting to look more appealing. Although it won't fix "Open with…".