[Fwd: Porting kio-slaves to GnomeVFS modules]
nf2 <[email protected]> Mon, 27 Dec 2004 16:49:23 +0100
| Newsgroups | gmane.comp.gnome.gnomemm |
|---|---|
| Message-ID | <[email protected]> |
Hi! Exploring the Common-VFS issue i am looking for a way to port kio-slaves to Gnome-VFS modules. Are there any plans to write a glibmm based C++ wrapper for the gnome-vfs-modules API? (Because at the moment only a gnome-vfs client wrapper exists AFAIK). I have started threads about this issue on kde-core-devel (and gnome-vfs-list): http://lists.kde.org/?t=110375795500003&r=1&w=3 General vfs discussion: http://lists.kde.org/?t=110353092000004&r=1&w=3 Norbert -------- Original Message -------- Subject: Porting kio-slaves to GnomeVFS modules Date: 22 Dec 2004 21:33:53 +0100 From: nf <[email protected]> To: kde core list <[email protected]>, gnome vfs list <[email protected]> Hi! AFAIK KDE seems to offer more VFS modules (io-slaves) than Gnome-VFS at the moment. It would be interesting if their code could be reused in Gnome-VFS modules instead of writing everything from scratch. One way of doing that would be to write a C++ wrapper on top of the Gnome-VFS-module API which acts like the KIO::SlaveBase class. Things that need to be looked at: 1) The SlaveBase::special() method. KIO can invoke this method on io-slaves for advanced operations. Perhaps Gnome-VFS needs an equivalent for that: An additional function, which passes customized structs, just like the callback structs. I don't know how many io-slaves use this method extensively - kio_http seems to be one of the worst in that respect. Perhaps http should just be excluded from the Common-VFS agenda at the moment... 2) Dependencies to KConfig of certain slaves to store configuration data. (smb for instance). 3) Dependencies to Password storage via DCOP. But that's easier to solve, because SlaveBase has a well defined API for that purpose. 4) Additional GVFS-Callback structures might be needed - but again that should be easy, because the API for calling back to the client seems to be "well-defined" in KIOs SlaveBase. 5) Metadata 6) "Q"-code inside io-slaves: Because QT is split into QTCore and QTGui in Qt4 a dependency of those modules to QtCore shouldn't be a problem. The GPL license also, because the ported slaves link to Qt and Gnome-VFS, and not the other way round... Alternatively KWIG could be used to mimic the "Q" stuff... +++ Resources: KIO: http://developer.kde.org/documentation/library/3.3-api/kio/html/index.html http://webcvs.kde.org/kdelibs/kio/ http://webcvs.kde.org/kdelibs/kio/kio/ (slavebase.h/cpp in particular) Code of the kioslaves: http://webcvs.kde.org/kdelibs/kioslave/ http://webcvs.kde.org/kdebase/kioslave/ KWIG: http://gtk-webcore.sourceforge.net/ Gnome-VFS: http://developer.gnome.org/doc/API/2.0/gnome-vfs-2.0/ http://cvs.gnome.org/viewcvs/gnome-vfs/libgnomevfs/ Callback Types http://cvs.gnome.org/viewcvs/gnome-vfs/libgnomevfs/gnome-vfs-standard-callbacks.h Module Methods http://cvs.gnome.org/viewcvs/gnome-vfs/libgnomevfs/gnome-vfs-method.h KIO->GnomeVFS bridge. http://www.scheinwelt.at/~norbertf/common-vfs/ Just some thoughts, really don't know if that would make sense... Norbert _______________________________________________ gnome-vfs-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-vfs-list