glib/docs/reference/gio/migrating.xml

<part id="migrating">
  <title>Migrating to GIO</title>

  <chapter>
    <title>Migrating from POSIX to GIO</title>
  
    <table id="posix-vs-gio">
      <title>Comparison of POSIX and GIO concepts</title>
      <tgroup cols="2">
        <thead>
          <row><entry>POSIX</entry><entry>GIO</entry></row>
        </thead>
        <tbody>
          <row><entry>char *path</entry><entry>GFile *file</entry></row>
          <row><entry>struct stat *buf</entry><entry>GFileInfo *info</entry></row>
          <row><entry>struct statvfs *buf</entry><entry>GFileInfo *info</entry></row>
          <row><entry morerows="1">int fd</entry><entry>GInputStream *in</entry></row>
          <row><entry>GOutputStream *out</entry></row>
          <row><entry>DIR *</entry><entry>GFileEnumerator *enum</entry></row>
          <row><entry>fstab entry</entry><entry>GUnixMountPoint *mount_point</entry></row>
          <row><entry>mtab entry</entry><entry>GUnixMountEntry *mount_entry</entry></row>
        </tbody>
      </tgroup>
    </table>  

  </chapter>

  <chapter>
    <title>Migrating from GnomeVFS to GIO</title>

    <table id="gnome-vfs-vs-gio">
      <title>Comparison of GnomeVFS and GIO concepts</title>
      <tgroup cols="2">
        <thead>
          <row><entry>GnomeVFS</entry><entry>GIO</entry></row>
        </thead>
        <tbody>
          <row><entry>GnomeVFSURI</entry><entry>GFile</entry></row>
          <row><entry>GnomeVFSFileInfo</entry><entry>GFileInfo</entry></row>
          <row><entry>GnomeVFSResult</entry><entry>GError, with G_IO_ERROR values</entry></row>
          <row><entry>GnomeVFSHandle &amp; GnomeVFSAsyncHandle</entry><entry>GInputStream or GOutputStream</entry></row>
          <row><entry>GnomeVFSDirectoryHandle</entry><entry>GFileEnumerator</entry></row>
          <row><entry>mime type</entry><entry>content type</entry></row>
          <row><entry>GnomeVFSMonitor</entry><entry>GFileMonitor</entry></row>
          <row><entry>GnomeVFSVolumeMonitor</entry><entry>GVolumeMonitor</entry></row>
          <row><entry>GnomeVFSVolume</entry><entry>GMount</entry></row>
          <row><entry>GnomeVFSDrive</entry><entry>GVolume</entry></row>
          <row><entry>-</entry><entry>GDrive</entry></row>
          <row><entry>GnomeVFSContext</entry><entry>GCancellable</entry></row>
          <row><entry>gnome_vfs_async_cancel</entry><entry>g_cancellable_cancel</entry></row>
        </tbody>
      </tgroup>
    </table>

    <section>
      <title>Trash handling</title>

      <para>
        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 <ulink url="http://www.freedesktop.org/wiki/Specifications/trash-spec">Desktop Trash Can</ulink> specification
        that is implemented in GIO. The location for storing trashed files 
        has changed from <filename>$HOME/.Trash</filename> to 
        <filename>$HOME/.local/share/Trash</filename> (or more correctly
        <filename>$XDG_DATA_HOME/Trash</filename>), which means that 
        there is a need for migrating files that have been trashed by 
        gnome-vfs to the new location.
      </para>
      <para>
        In gnome-vfs, the <filename>trash://</filename> 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 <filename>trash://</filename>
        implementation has been moved to gvfs and applications can simply
        monitor that location:
      </para>
<informalexample><programlisting>
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);

  /* ... */

}       
</programlisting></informalexample> 
      <para>
        GIO exposes some useful metadata about trashed files. There are
        trash::orig-path and trash::deletion-date attributes. The 
        standard::icon attribute of the <filename>trash://</filename> 
        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.
      </para>
      <para>
        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.
      </para>
    </section>

    <section>
      <title>Operations on multiple files</title>

      <para>
        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. 
      </para>
      <para>
        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(). 
      </para>

    </section>

    <section>
      <title>Mime monitoring</title>

      <para>
        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
        <ulink url="http://bugzilla.gnome.org">bugzilla.gnome.org</ulink>.
      </para>
    </section>
  </chapter>

  <chapter>
    <title>Migrating from GConf to GSettings</title>

    <section>
      <title>Conceptual differences</title>

      <para>
        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.
      </para>
      <para>
        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.
      </para>
    </section>

    <section>
      <title>GConfClient API conversion</title>

      <para>
        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:
        <table id="gconf-client-vs-gsettings">
          <tgroup cols="2">
            <thead>
              <row><entry>GConfClient</entry><entry>GSettings</entry></row>
            </thead>
            <tbody>
              <row><entry>gconf_client_set()</entry><entry>g_settings_set()</entry></row>
              <row><entry>gconf_client_get()</entry><entry>g_settings_get()</entry></row>
              <row><entry>gconf_entry_get_is_writable()</entry><entry>g_settings_is_writable()</entry></row>
              <row><entry>gconf_client_notify_add()</entry><entry>not required, the #GSettings::changed signal is emitted automatically</entry></row>
              <row><entry>GConfChangeSet</entry><entry>g_settings_delay()</entry></row>
            </tbody>
          </tgroup>
        </table>
      </para>
    </section>

    <section>
      <title>Change notification</title>

      <para>
        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.
      </para>
      <para>
        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.
      </para>
      <para>
        GSettings also notifies you about changes in writability of keys,
        with the #GSettings::writable-changed signal.
      </para>
    </section>

    <section>
      <title>Schema conversion</title>

      <para>
        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
        <programlisting>
<![CDATA[
<type>string</type>
<default>rgb</default>
]]>
        </programlisting>
        becomes
        <programlisting>
<![CDATA[
<key name="rgba_order" type="s">
  <default>'rgb'</default>
</key>
]]>
        </programlisting>
      </para>
      <para>
        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
        <programlisting>
<![CDATA[
<key>/schemas/desktop/gnome/font_rendering/antialiasing</key>
]]>
        </programlisting>
        becomes
        <programlisting>
<![CDATA[
<schema id="org.gnome.font" path="/desktop/gnome/font_rendering/">
  <key name="antialiasing" type="s">
]]>
        </programlisting>
      </para>
      <para>
        GIO comes with a commandline tool
        <link linkend="gsettings-schema-convert">gsettings-schema-convert</link>
        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.
      </para>
    </section>

    <section><title>More information</title>
      <para>
        More information about migration from GConf to GSettings will appear
        here soon. Topics to cover:
        <itemizedlist>
          <listitem><para>Defaults</para></listitem>
          <listitem><para>Change sets</para></listitem>
          <listitem><para>Data conversion</para></listitem>
        </itemizedlist>
      </para>
    </section>
  </chapter>

</part>