Want to help GNOME? Please port a module to GIO! See http://live.gnome.org/GioPort for instructions. I’d really appreciate a patch for librsvg (or any other not-yet ported module). Nautilus uses GIO. However, it still links against gnome-vfs and (one of?) the reason(s) is librsvg. Perhaps that is caused by other things as well. If so, please provide patches for those modules as well.
Note: Please keep the wiki page up to date. Just create an account and you will be able to edit it. Some modules might have been ported by the maintainer already (without the page being updated). If so, please update the wiki page as well.
9 Replies to “Coder? Please port a module to GIO!”
Comments are closed.
I’ve heard about GIO for a couple of times now, is there a list of benefits (compared to gnome-vfs) somewhere?
Why does nautilus need to directly link librsvg anyways? Does it do things that go beyond what gdk-pixbuf supports?
Bob: I just used ldd.
mik: It will be explained in the release notes for 2.22. Basically: easier to use for developers (so hopefully more apps will use it). For users: no more authentication dialogs popping up. ‘Mounts’ are shared across applications (you don’t have to authenticate in app again). Using fuse non-gio apps should still be able to access virtual files. At one point it will be faster than gnome-vfs as well. There might be some regressions on the short term though (due to the big code change).
mik: you can read about the benefits at http://www.gnome.org/~alexl/presentations/guadec2007-gvfs.pdf
Or even better fix ftp:// in gio!
I get a “403” when I click that link
Vidar: I was upgrading the server to a newer moinmoin version. It should work now (still needs a bit of work).
There are about a hundred source packages in Debian that Build-Depend on libgnomevfs2-dev. No doubt there are other codebases that aren’t in Debian (e.g. end-user apps). That sounds like a lot of porting.
Instead of porting a module to this experimental GIO thing, how about porting GIO to gnome-vfs interface (possibly using existing libgnomevfs source code), so that all modules are immediately usable with GIO? In particular, apps would immediately get the benefits of fewer “direct” (i.e. link-time) dependencies, shared authentication & caches (and possibly shared connections), and isolation from backend crashes. True, we can’t get all of the benefits without changing individual applications, but this seems like the only practical path to retiring gnome-vfs any time soon.
Peter: Gnome-vfs is crap compared to GIO. There are design issues with gnome-vfs (it is *old*). Making GIO work plug into gnome-vfs means that these issues won’t be solved (due to design issues gnome-vfs). Further, I do not agree that this is practical; gnome-vfs will continue to work eventhough it will be deprecated. The effort can better be spend on bugfixing GIO. Not bugfixing some badly working interaction between gnome-vfs and GIO.