POSIXGIOchar *pathGFile *filestruct stat *bufGFileInfo *infostruct statvfs *bufGFileInfo *infoint fdGInputStream *inGOutputStream *outDIR *GFileEnumerator *enumfstab entryGUnixMountPoint *mount_pointmtab entryGUnixMountEntry *mount_entry GnomeVFSGIOGnomeVFSURIGFileGnomeVFSFileInfoGFileInfoGnomeVFSResultGError, with G_IO_ERROR valuesGnomeVFSHandle & GnomeVFSAsyncHandleGInputStream or GOutputStreamGnomeVFSDirectoryHandleGFileEnumeratormime typecontent typeGnomeVFSMonitorGFileMonitorGnomeVFSVolumeMonitorGVolumeMonitorGnomeVFSVolumeGMountGnomeVFSDriveGVolume-GDriveGnomeVFSContextGCancellablegnome_vfs_async_cancelg_cancellable_cancel

The handling of trashed files has been changed in GIO, compared to gnome-vfs. gnome-vfs has a home-grown trash implementation that predates the freedesktop.org Desktop Trash Can specification that is implemented in GIO. The location for storing trashed files has changed from $HOME/.Trash to $HOME/.local/share/Trash (or more correctly $XDG_DATA_HOME/Trash), which means that there is a need for migrating files that have been trashed by gnome-vfs to the new location. In gnome-vfs, the trash:// scheme offering a merged view of all trash directories was implemented in nautilus, and trash-handling applications had to find and monitor all trash directories themselves. With GIO, the trash:// implementation has been moved to gvfs and applications can simply monitor that location: static void file_changed (GFileMonitor *file_monitor, GFile *child, GFile *other_file, GFileMonitorEvent event_type, gpointer user_data) { switch (event_type) { case G_FILE_MONITOR_EVENT_DELETED: g_print ("'%s' removed from trash\n", g_file_get_basename (child)); break; case G_FILE_MONITOR_EVENT_CREATED: g_print ("'%s' added to trash\n", g_file_get_basename (child)); break; default: ; } } static void start_monitoring_trash (void) { GFile *file; GFileMonitor *monitor; file = g_file_new_for_uri ("trash://"); monitor = g_file_monitor_directory (file, 0, NULL, NULL); g_object_unref (file); g_signal_connect (monitor, "changed", G_CALLBACK (file_changed), NULL); /* ... */ } GIO exposes some useful metadata about trashed files. There are trash::orig-path and trash::deletion-date attributes. The standard::icon attribute of the trash:// itself provides a suitable icon for displaying the trash can on the desktop. If you are using this icon, make sure to monitor this attribute for changes, since the icon may be updated to reflect that state of the trash can. Moving a file to the trash is much simpler with GIO. Instead of using gnome_vfs_find_directory() with %GNOME_VFS_DIRECTORY_KIND_TRASH to find out where to move the trashed file, just use the g_file_trash() function.

gnome-vfs has the dreaded gnome_vfs_xfer_uri_list() function which has tons of options and offers the equivalent of cp, mv, ln, mkdir and rm at the same time. GIO offers a much simpler I/O scheduler functionality instead, that lets you schedule a function to be called in a separate thread, or if threads are not available, as an idle in the mainloop. See g_io_scheduler_push_job().

gnome-vfs offered a way to monitor the association between mime types and default handlers for changes, with the #GnomeVFSMIMEMonitor object. GIO does not offer a replacement for this functionality at this time, since we have not found a compelling use case where #GnomeVFSMIMEMonitor was used. If you think you have such a use case, please report it at bugzilla.gnome.org.

Conceptually, GConf and GSettings are fairly similar. Both have a concept of pluggable backends. Both keep information about keys and their types in schemas. GSettings is more strict about requiring a schema whenever you want to read or write a key. Both have a concept of mandatory values, which lets you implement lock-down. One difference in the way applications interact with their settings is that with GConf you interact with a tree of settings (ie the keys you pass to functions when reading or writing values are actually paths with the actual name of the key as the last element. With GSettings, you create a GSettings object which has an implicit prefix that determines where the settings get stored in the global tree of settings, but the keys you pass when reading or writing values are just the key names, not the full path.

Most people use GConf via the high-level #GConfClient API. The corresponding API is the #GSettings object. While not every GConfClient function has a direct GSettings equivalent, many do: GConfClientGSettingsgconf_client_set()g_settings_set()gconf_client_get()g_settings_get()gconf_entry_get_is_writable()g_settings_is_writable()gconf_client_notify_add()not required, the #GSettings::changed signal is emitted automaticallyGConfChangeSetg_settings_delay()

GConf requires you to call gconf_client_add_dir() and gconf_client_notify_add() to get change notification. With GSettings, this is not necessary; signals get emitted automatically for every change. The #GSettings::changed signal is emitted when an individual key is changed, #GSettings::keys-changed is emitted when multiple keys are changed at the same time (e.g. when g_settings_apply() is called on a delayed-mode GSettings instance. GSettings also notifies you about changes in writability of keys, with the #GSettings::writable-changed signal.

One possible pitfall in doing schema conversion is that the default values in GSettings schemas are in the format of a serialized #GVariant, and the types are specified as #GVariant type strings. This means that strings need to include quotes in the XML, so string rgb ]]> becomes 'rgb' ]]> Another possible complication is that GConf specifies full paths for each key, while a GSettings schema has a 'path' attribute that contains the prefix for all the keys in the schema, and individual keys just have a simple name. So /schemas/desktop/gnome/font_rendering/antialiasing ]]> becomes ]]> GIO comes with a commandline tool gsettings-schema-convert that can help with the task of converting a GConf schema into an equivalent GSettings schema. The tool is not perfect and may need assistence in some cases.

More information about migration from GConf to GSettings will appear here soon. Topics to cover: Defaults Change sets Data conversion