1. Background
gio is the new i/o library for gnome, scheduled to replace gnome-vfs. It ships with glib as a separate library called "libgio-2.0". Libgio contains abstractions for file i/o, file types and things like that. It also contains default implementations for local file i/o.
In addition to libgio there is a module called "gvfs", which implements a userspace virtual filesystem using daemons handling each mount and dbus to talk to these daemons. It automatically plugs into libgio and extends its functionality.
The goal for gio/gvfs is to ship with Gnome 2.22, and we've gotten quite far with that. Nautilus has been totally switched over, and many other pieces of the desktop are working on switching. However, there are still parts that need filling out. This page is a listing of bite-sized chunks of work needed in the gio stack. If you're interested, please help out with finishing some of these!
For GIO porting work in the broader Gnome stack, see GioPort.
If you're interested in helping out with this work, join us in the #nautilus channel on irc.
1.1. Gio TODO
Gio is now in the glib. Its mostly API frozen, although we might do some API additions.
- API Docs This is in a pretty good state now. The one major omission in the current docs is examples. We need a number of good examples.
- Other Docs
- We need a porting guide (similar in spirit to the porting chapters for other things that you can see in the GTK+ api docs. It should cover conversion from both POSIX and gnome-vfs to gio. There is an (almost empty) stub of a migration document in the api docs.
- Test and extend win32 support as needed
- I've done some work on win32, but this hasn't been tested or updated recently. Someone interested in win32 should look this over.
1.2. GVfs TODO
Ability to build backends outside tree (525476)
- Right now the header files and libraries are not really set up in a way that you can build gvfs backends outside of the gvfs source tree. The header files and libs needs some cleaning up so that this is possible. I think we should avoid doing this for the first release at least and only do in-tree backends. This way we can tweak the APIs as needed.
Reverse map fuse filenames (509617) DONE
- We would like to recognize filenames of the form $home/.gvfs/* and automatically convert these to gvfs files instead of ordinary local files. That way we will get correct icons, display names, etc for them in e.g. the file selector.
Implement g_file_output/input_stream_query_info() for gvfs (520244) DONE
- This requires marshalling GFileInfo over the custom stream protocol, which is some work.
- Per backend config options
- We want to be able to store configuration options for mounts. For instance, you might want to configure the filename encoding for a specific ftp site. We'd have to figure out some way to store this and an easy way for the backends to access it. We also want to expose this in the UI somewhere/somehow. This is probably a post 2.22 thing.