KIOFuse in kdereview

Alexander Saoutkin a.saoutkin at gmail.com
Mon Nov 4 22:08:44 GMT 2019


Hi everyone,

KIOFuse (https://invent.kde.org/kde/kio-fuse) has been moved to kdereview.

KIOFuse is a project started by Fabian Vogt that allows the possibility to
mount KIO filesystems in the local system; therefore exposing them to
POSIX-compliant applications such as Firefox and LibreOffice. KIOSlaves are
a powerful feature within the KIO framework, allowing KIO-aware
applications such as Dolphin to interact with services out of the local
filesystem over URLs such as fish:// and smb://. However, KIO-unaware
applications are unable to interact seamlessly with KIO Slaves. For
example, editing a docx file in gdrive:/ in LibreOffice will not save
changes to your Google Drive seamlessly. KIOExec is one of the fallbacks
that is used, but is not desirable. One potential solution is to make use
of FUSE, which is an interface provided by the Linux kernel, which allows
userspace processes to provide a filesystem which can be mounted and
accessed by regular applications. KIOFuse is a feature that has been
requested many times before, case in point this very active 15 year-old
bugzilla bug report [0] and several reddit threads [1] [2] [3] [4]. The
project was further developed by me as a GSoC project [5], and both me and
Fabian are happy to see KIOFuse go through the kdereview process now.

KIOFuse can be used standalone, but there is also work to integrate KIOFuse
closer with KIO [6], allowing seamless “integration” between the two.

Currently, KIOFuse has been tested to work on Linux, although there are no
technical reasons why it can’t work on FreeBSD. It can potentially work on
macOS [7], and we’d be happy for people to test this for us if there is
demand for it. KIOFuse currently uses the low-level libfuse API, but there
is a Windows-based library that has a compatibility layer with the
high-level libfuse API [8]. If one would like KIOFuse to work on Windows,
one could explore the creation of a low-level libfuse API compatibility
layer; it would probably also require a bit of a refactor of the KIOFuse
code.

The ideal destination is extragear, due to KIOFuse being written for C++17,
and frameworks requiring to be compiled on C++11-compliant compilers or
newer. A move to KF6 in the future could be desirable.

Kind regards,

Alexander Saoutkin (feverfew)

[0]: https://bugs.kde.org/show_bug.cgi?id=75324

[1]:
https://www.reddit.com/r/kde/comments/a5a0zq/is_kiofuse_ever_going_to_be_a_thing/

[2]:
https://www.reddit.com/r/kde/comments/9exqqu/imo_everything_about_kde_is_the_best_except_one/

[3]:
https://www.reddit.com/r/kde/comments/9i3ml8/mpv_does_not_want_to_open_video_files/

[4]:
https://www.reddit.com/r/kde/comments/77ekkm/plasma_511_review_keep_the_momentum_going/

[5]:
https://summerofcode.withgoogle.com/archive/2019/projects/4621805883490304/

[6]: https://phabricator.kde.org/D23384

[7]: https://osxfuse.github.io/

[8]: https://github.com/billziss-gh/winfsp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20191104/8d9bea6e/attachment.htm>


More information about the kde-core-devel mailing list