On Thu, 2013-05-02 at 17:44 +0200, jf dockes org wrote:
Bastien Nocera writes: > On Thu, 2013-05-02 at 16:46 +0200, jf dockes org wrote: > > Bastien Nocera writes: > > > On Thu, 2013-05-02 at 12:44 +0200, jf dockes org wrote: > > > > Hi, > > > > > > > > Apologies in advance if this is a FAQ, please just point me to the right > > > > place... The question: > > > > > > > > Is it possible to write a GVFS backend out of the Gnome source tree ? > > > > > > No. The API isn't public. > > > > Thanks, and sorry to be a little thick, just so I'm sure I fully understand: > > this means that there is no way to extend (à la KIO) a GVFS/GIO-based file > > manager to support another kind of "file store/catalog" except by modifying > > Gnome source ? > > If by "Gnome source" you mean gvfs, then yes, that's correct. > > What were you looking to do? I was thinking of an interface to a search application (Recoll). It has a KIO that some people use (I don't use it because displaying file names as search results is generally not helpful for my needs, but it all depends on the data). I was wondering if I could write the same kind of module for GVFS, with the idea that it might be usable with, for exemple Thunar. This is very preliminary, and there may be other reasons why this would not work, but I'm just starting. Such a module would bring obviously unacceptable dependancies to the main tree, which is why, to make any sense, it has to live outside the tree, and be installable/loadable independantly (like the KIO is to KDE). I was expecting the GVFS/GIO to have this kind of extensibility, because, once you've defined such an interface, it seems natural to let other people add unexpected stuff under it... But maybe I'm just completely missing the point, this is my first brush with the subject.
Hi JF I too was surprised to find gvfs didn't have a facility for external extensions. I've got round this somewhat, if you want an example of how it's possible, have a look at SynCE in sourceforge, https://sourceforge.net/projects/synce/ The project is to connect to windows ce devices, and I implemented an out of tree gvfs module when it took over from gnomevfs. I found it doubly odd that gnomevfs could deal with external extensions and gvfs cant. The source is mostly some horrible autotools messing around which builds a single source file and a header against the stock gvfs "daemon" source files. It looks much more complicated than it is because I've tried to keep it backwards compatible against older versions of gvfs. I haven't needed to change anything related to the gvfs API in my own code for 18 months, so the interface is actually remarkable stable. To the gvfs devs, are there any plans to ever have a public API ? I don't pretend to know how complex the internals are, or what plans are afoot to change anything in there, but in seems a shame that you've made it so easy to implement new backends, but haven't exported the interface. If libdaemon were actually a shared library, all we would need would be a few header files, and job done. Ta Mark
Attachment:
signature.asc
Description: This is a digitally signed message part