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

[Alexander Saoutkin]

feverfew added a comment.


  In D23384#570349 <https://phabricator.kde.org/D23384#570349>, @ngraham wrote:
  
  > 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.
  
  
  Yes, that's precisely why. !2 <https://invent.kde.org/kde/kio-fuse/merge_requests/2> implements seeking to any point in the file without having to download all of it. I'll rebase all of it such that you can test all of it easily tomorrow.

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/1f294821/attachment.html>