Background

gio is the new i/o library for gnome, scheduled to replace gnome-vfs. Its ship 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.

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.

• All gio bugs

GVfs TODO

• Ability to build backends outside tree (gnomebug: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 (gnomebug:509617)
  • 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 (gnomebug:520244)
  • 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.

• All gvfs bugs. We need to fix all crashers and important regressions.

Missing Backends

There are a bunch of backends that we want:

• burn: backend
  • This requires some work on write support (gnomebug:509602) and file change monitor support (gnomebug:512864)
• http/https/webdav

  • Initial work in this area has been started by ChristianKellner. Also see Dan Winship's work on a libsoup-based stream implmentation.

• fonts and themes (gnomebug:517632)
  • Not quite as important as the others, but at least fonts is accessible from the appearance capplet via the "Go to Fonts Folder" button and offers some extra functionality such as preview and easy removal and installation of fonts.

Nautilus

Nautilus 2.21.x is gio-only, and seems to be mostly working,

• connect to server?
  • The gio model is stateful, which essentially means that it has a mount operation and state connected to the mount. gnome-vfs doesn't have this, but to sort of hack that in the "connect to server" operation was introduced. We need to rethink what this means in the gio world.
• watch for unmounted events
  • The file monitor APIs in gio added the UNMOUNTED event. We need the nautilus windows to monitor for this and close themselves (or go to $home for browser windows)

• Nautilus bugs in gio component

Gtk+

There is some parts of gio that should really be in Gtk+ that apps might need. Long term this should go into Gtk+, but for now we might want to put these in a separate desktop library so that apps can start using gio easily before the next Gtk+ release.

• GIcon renderer (gnomebug:522084)

  • GIcon is an abstract object representing an icon. Its in glib, so it has no UI in the API. We need a renderer API for this so that you can easily get a GdkPixbuf for an icon. However, this needs to go into the Gtk+ level of the stack. Patch in bugzilla.

• GIcon support in GtkImage (gnomebug:522084)

  • It should be easy to display a GIcon in a GtkImage. Patch in bugzilla.

• GtkFileChooser should use gio directly, not the filesystem backend abstraction.

• Use GFileMonitor where possible
  • I think the recent files code and the bookmarks code could use this functionallity

    • The GtkRecentManager should use the content type API to figure out the MIME type and the default application for every newly added items as well.