[PATCH] Multi-Protocol IO-Slave
kde-dev at emailgoeshere.com
Sun Jan 13 15:17:25 GMT 2008
On Sunday 13 January 2008, nf2 wrote:
> Apart from the desktop/toolkit independence (just GLib and D-Bus) and
> that one VFS is always better than two (For 3rd party applications the
> situation was like the donkey stuck between two haystacks, they avoided
> to choose KIO or Gnome-VFS - which sucks) - yes - i think GIO/GVFS is
> better than KIO and you will want that stuff.
Some of the things you mentioned sound nice, but apart from the requiring glib
thing, I have a few questions:
First, on http://live.gnome.org/GioToDo it says, "There is some parts of gio
that should really be in Gtk+ that apps might need. Long term this should go
into Gtk+, but for now we might want to put these in a separate desktop
library so that apps can start using gio easily before the next Gtk+
While these classes could be worked around by having KDE implementations, I
find it a bit troubling that they want to move some parts of GIO into GTK.
Then your dependencies go from glib/dbus to glib/dbus/gtk, at least by
default. What other parts of GIO/GVFS might they at some point decide really
belong in GNOME-specific libraries?
"One complaint about GnomeVFS is that mount points cannot be accessed by
non-GnomeVFS-aware applications. GVFS uses a FUSE bridge to make these
publicly accessible...This FUSE bridge makes it possible for literally any
application to use GVFS, even if it is not aware of it."
Perhaps something to consider for KIO in the future?
Personally, I'm all for a single network transparency library (or a single
authentication caching library, which would serve the purpose). I do think
it's utterly stupid that the GNOMEs couldn't contribute to KIO, which already
has a bazillion working, useful KIOslaves, unless they felt (as they seem to)
that GIO/GVFS is better by design. Still, it does reek a bit of "we just
can't allow ourselves to use anything with a K in it" syndrome.
More information about the kde-core-devel