D23384: [WIP] Adding support for mounting KIOFuse URLs for applications that don't use KIO

[Nathaniel Graham]

ngraham added a comment.


  In D23384#570125 <https://phabricator.kde.org/D23384#570125>, @dfaure wrote:
  
  > @ngraham AFAIK gnome has a trick where a fuse mount is created, its path is passed to the application being started, and the application, if it supports gvfs, re-translates that into a URL and uses that instead if it makes more sense. This way "dumb" apps get a local file (with all the limitations of doing synchronous I/O over the network) and network-transparent applications use URLs.
  >  On the other hand, the KDE logic is "if the app takes %f and not %u in the Exec line, it doesn't support remote URLs, so we need to download the file first" (that's done by kioexec). If you see a "download first" check if kioexec is running. But if it's the app doing it, then I have no idea.
  
  
  `kioexec` is not running during any of these lengthy downloads. Totem, VLC, and SMplayer all have %U in their desktop files, FWIW.
  
  We may want to rethink this logic anyway. Any app that doesn't integrate with ioslaves should get the FUSE path rather than a locally-downloaded file, irrespective of whether or not its desktop file has %f or %u IMO. There are just too many disadvantages to the locally downloaded file approach, which is why we're doing this FUSE thing in the first place.
  
  Perhaps the "lengthy local download first" issue is caused by not having https://invent.kde.org/kde/kio-fuse/merge_requests/2 yet.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D23384

To: feverfew, fvogt, davidedmundson, dfaure, ngraham
Cc: sitter, davidedmundson, kde-frameworks-devel, ngraham, LeGast00n, GB_2, michaelh, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20191201/cf3996ce/attachment-0001.html>