Common VFS: GKIO experiment
nf2 at scheinwelt.at
Thu Dec 9 22:57:26 EET 2004
On Wed, 2004-12-08 at 11:33, Waldo Bastian wrote:
> [Cross-posted this time, with some changes to the dispatch part]
> On Wednesday 08 December 2004 01:12, nf wrote:
> > In order to find a way out of this situation, i would like to start an
> > experiment: To write a (KDE/C++) wrapper to Gnome-VFS which looks and
> > acts like the KIO-API - "GKIO". Then write a number of test-cases, which
> > test the GKIO-API for KIO requirements and compatibility. Once this
> > tests work, i want to try plugging GKIO into kde-core libs (instead of
> > original KIO code).
> The API you are looking for is the io-slave API. In particular
> kdelibs/kio/kio/slaveinterface.h and kdelibs/kio/kio/slavebase.h
> The easiest is to start by making a single (out of process) ioslave, there are
> plenty of io-slaves available as example, but the file ioslave
> (kdelibs/kioslave/file) is probably relatively close to what you need.
> In general io-slaves don't use the Qt event loop at all, so you don't need to
> merge it either. If you need the glib event loop you may need to merge it
> with SlaveBase::dispatchLoop() which handles the communication between
> application and io-slave. Typically the slave is idle when it hangs around in
> dispatchLoop(), waiting to get a new command from the application, so I don't
> think you would have much glib events to process there.
> If you need to do things in-process (but I can't see why actually) you can
> have a look at the data io-slave, kdelibs/kio/kio/dataslave.cpp
Thanks! Although my approach was a bit different, this seems to be
* Write a "generic" Gnome-VFS io-slave, which gets "reused" for (almost)
all protocols. That would mean all .protocol files map to the same
gkio-slave.so library. This is possible, because the constructor
SlaveBase() is told, which protocol it has to handle.
More information about the xdg