KIO GDrive 1.0 released
aelog.org/kio-gdrive-released/Posted Sep 30, 2016, 2:07 PM UTC
5544
aelog.org
Yes, finally! Thank you so much for working on this :)
5
Can someone explain to me why KIO (and GVfs for Gnome) exists at all? What does it provide over a simpler, desktop-agnostic FUSE filesystem?
The documentation doesn't give me much info, unless there's something other than the API reference info that I'm missing.
3
kio does not require setup via mount. instead acts more like a browser where one enters the URL and you're there, no setup. It's very convenient for accessing files on any number of boxes of ssh (fish://). Additionally, it seems to perform a bit better in terms of caching directory tree after viewing and such.
Personally, not having to mount them and keep track of random local directory paths makes a lot more sense. I think of the file as remote (fish://someuser@remotebox/path/to/file), not /some/local/path. Just as it would be weird if you browsed reddit as /reddit/r/kde instead of http://reddit.com/r/kde. I keep a number of fish:// to various boxes and directories which is nice to instantly jump in without additional local setup.
Obviously, for low level tools and what not fuse is the only and sometimes better option.
5
You don't have to manually mount as FUSE filesystem. That'd be the job of whatever would replace KIO, or maybe it would be the theoretical new job for KIO.
Plus there's nothing stopping the application from allowing you to use the procotol:// convention. That's a frontend thing.
Essentially, everything from your end would be the same, the only change is how it works in the background, where now developers can share more work instead of reimplementing everything.
2
I get that, but then do it. Until then.
1
You mean writing fuse filesystems to access the desktop, trash, html man pages, info pages or baloosearch? Sounds like a bit over-complicating things to me. Using fuse as backend for some kio slaves makes more sense...replacing it not really as they don't even do the same things. Fuse is for filesystems in userspace, kio for unified input/output.
1
Sounds like a bit over-complicating things to me.
How's that more complicated than KIO? It's the simplest approach ever and the most faithful to the Unix philosophy of doing things. Take a look at Plan 9 and tell me that's over-complicated.
Fuse is for filesystems in userspace, kio for unified input/output.
Filesystems cover that. Again, Plan 9 is one example where you can see that at work.
1
- KIO can use FUSE as a backend and still map those URLs to the real mounted paths.
- KIO's URLs are unusable by all non-KDE apps (eg: plain old xterm, vim, etc).
Using FUSE as a backend does not mean they'd have to drop all these features you mention.
2
When did I disagree with you? I simply stated the features that kio has that fuse does not that I value. Never did I disagree that fuse could be used as the basis and being a programmer I can appreciate no implementing things in multiple places. It also begs why fuse never came back and did so or perhaps they did...considering kio was the inspiration.
Please read what people write, not what you assume them to think.
2
Gee, what's with the aggressive tone.
I never said (or implied) you disagreed with me (if that would have made sense, considering that was my first comment here), I merely exposed how kio can easily use fuse as a backend, and offer those extra features you seem to value.
1
A whole bunch of years, KIO came first, then GVFS and some time later, FUSE.
3
Why then are KIO slaves still being developed instead of seeking integration with FUSE? Or are slaves like this one just FUSE wrappers for backwards compatibility reasons?
2
Kio is better for some things than fuse.
Kio can power a web browser easily. Fuse would suck horrendously at that.
Obviously fuse is better at some things too.
It's not a simple x is better than y, but just different... And at that point migration is hard.
4
KIO is multiplatform fuse is only for the linux kernel. So no windows, BSD and mac support. It means your app can't rely on fuse for functional and be multi-platform.
3
Kio can power a web browser easily. Fuse would suck horrendously at that.
How? There are C++ APIs for dealing with files just like KIO has its own. Plus most browsers ship with at least rudimentary file:/// protocol handling.
1
KDE exists on more than just Linux. And FUSE is a very simple layer that invokes syscall overhead.
2
FUSE works for all platforms supported by KDE (in Windows through Dokan). And particularly FUSE's simplicity is what's attractive as a universal platform. I don't think the performance would be a problem for most usecases (compared to KIO) and the entire community would gain a lot from avoiding the fragmentation.
3
GVfs is not an equivalent in gnome for kio...gio is. GVfs is just one of the the underlying structures it depends on.
2
I get the following error when trying to install...
Anyone know what to do here?
glyko@glyko-desktop:~/Downloads/Programs/kio-gdrive-1.0.0/build$ cmake -DCMAKE_INSTALL_PREFIX=/usr .. CMake Warning at /usr/local/share/ECM/find-modules/FindKF5.cmake:74 (find_package): Could not find a package configuration file provided by "KF5I18n" (requested version 5.14.0) with any of the following names:
KF5I18nConfig.cmake
kf5i18n-config.cmake
Add the installation prefix of "KF5I18n" to CMAKE_PREFIX_PATH or set "KF5I18n_DIR" to a directory containing one of the above files. If "KF5I18n" provides a separate development package or SDK, be sure it has been installed. Call Stack (most recent call first): CMakeLists.txt:28 (find_package)
-- Could NOT find KF5I18n: found neither KF5I18nConfig.cmake nor kf5i18n-config.cmake CMake Warning at /usr/local/share/ECM/find-modules/FindKF5.cmake:74 (find_package): Could not find a package configuration file provided by "KF5KIO" (requested version 5.14.0) with any of the following names:
KF5KIOConfig.cmake
kf5kio-config.cmake
Add the installation prefix of "KF5KIO" to CMAKE_PREFIX_PATH or set "KF5KIO_DIR" to a directory containing one of the above files. If "KF5KIO" provides a separate development package or SDK, be sure it has been installed. Call Stack (most recent call first): CMakeLists.txt:28 (find_package)
-- Could NOT find KF5KIO: found neither KF5KIOConfig.cmake nor kf5kio-config.cmake CMake Error at /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 (message): Could NOT find KF5 (missing: I18n KIO) (Required is at least version "5.14.0") Call Stack (most recent call first): /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE) /usr/local/share/ECM/find-modules/FindKF5.cmake:110 (find_package_handle_standard_args) CMakeLists.txt:28 (find_package)
-- Configuring incomplete, errors occurred! See also "/home/glyko/Downloads/Programs/kio-gdrive-1.0.0/build/CMakeFiles/CMakeOutput.log". glyko@glyko-desktop:~/Downloads/Programs/kio-gdrive-1.0.0/build$
1
You're missing ki18n and kio, install them from your package manager.
1
I cant find those packages in the package manager gui or with apt-get...
What now?
1
Which distribution? There are probably called in a different way...
1
KDE Neon
1
KIO is one of the best things in KDE and this is another great addition. Thank you for that!
Edit: I wish gnome software worked with KIO as well. In my dreams heh..
I would rather standard tools were used in the backend to actually mount remote filesystems so that all apps [regardless of toolkit] worked seamlessly with remote files.
Try this?
https://techbase.kde.org/Projects/KioFuse
I think that was abandoned 4 years ago.
If only it could integrate as well.
It could integrate better if it were written, IMO. Mounted filesystems work equally well for all DE's, while KIO only works for KDE.
if that were the case i bet everyone would be way happier. everyone would accept kernel syscall roundtrip in split-second.