This is a temporary change: once the port to GSettings is complete and
once it has been decided to stop using gconf, this should be removed to
make sure the GSettings schema is following the best practices for key
naming.

The baobab code is using global variables, so it's easy to avoid
creating new GSettings object.

In general, it's likely that references to commonly-accessed or
monitored GSettings object will be kept.

Also use GSettings to monitor the toolbar style configured in GNOME.

A few notes:

  + This is conditional code that is enabled with
    DESKTOP_SCHEMAS_PORTED. It's not enabled by default since it
    requires a GNOME-wide GSettings schema that is not yet available.

  + We're using g_settings_bind_with_mapping(): this works like
    g_settings_bind(), except that we provide a mapping function to
    decide how to convert from the GVariant coming from GSettings to the
    GValue that will be used to set the property. The
    +baobab_get_mapping_toolbar_style() implements such a mapping
    function. In case of failure, FALSE should be returned.

  + We use g_settings_bind_with_mapping() to monitor the changes to the
    setting key, but we don't need to reflect any change by writing to
    this key. So we use G_SETTINGS_BIND_GET instead of
    G_SETTINGS_BIND_DEFAULT. This means we don't have to provide a
    mapping function for the SET operation.

  + G_SETTINGS_BIND_SET is also available for cases where only the SET
    mapping is needed.

This should probably have been done earlier in the tutorial ;-)

baobab_gconf_get_string_with_default() is simple and needed only once,
so we can just remove it by including the code from where it was called.

This means we can safely remove the gconf_client_add_dir() call for this
gconf directory.

This change is really similar to the previous one (799b83df).

One more step to get rid of gconf for skip_scan_uri_list. We don't use
gconf anymore in baobab-prefs.c.

A few notes:

  + We're calling g_settings_set_strv() with an explicit size. It is
    also possible to use -1 instead, if the array is NULL-terminated.

We continue moving away from gconf for skip_scan_uri_list.

A few notes:

  + This is similar to the previous change (1c6ffb12), except that here,
    we're not using the size of the array that we could get with
    g_settings_get_strv(): instead, we rely on the fact that the array
    is NULL-terminated.

A few notes:

  + In gconf, we were getting a list, which resulted in a GSList. With
    GSettings, we get an array. So the code needs to be adapted a bit.

  + We're using an accessor here: g_settings_get_strv(). It would have
    been possible to use g_settings_get() directly:
      g_settings_get (settings, key, "as", &variable);

We simply get the initial value with g_settings_get_boolean() and then
monitor changes.

A few notes:

  + Compared to the previous gconf code, we now support changes of the
    key that are not done via the prefs dialog.

  + The prefs dialog doesn't need to know about the main part of the
    application now: it just cares about changing the setting key.

We use g_settings_bind() to directly link the state of a checkbox to a
setting key.

A few notes:

  + We created a new GSettings to access the key we wanted. But
    g_settings_bind() will keep a reference to it, so we can safely
    unreference it.

  + The checkbox will be destroyed once the prefs dialog is closed.
    But there's no need to call g_settings_unbind(): the binding will
    automatically be removed once the object is finalized.

Instead of using gconf to monitor changes to the subfolder tooltip
visibility, we use the changed signal of GSettings. This enables us to
get rid of the gconf handling for that part.

A few notes:

  + We can specify the key we're interested in for the changed signal
    with a detail: we therefore connect to
    "changed::baobab_subfoldertips_visible".

Instead of using gconf to get the value of this key, we use the
GSettings API.

It would have been easier to use g_settings_bind(), but the
BaobabRingschart object doesn't have a real property for tooltip
visibility. We can see here that implementing properties properly in
objects makes the use of GSettings easier (even though this is still
relatively easy).

A few notes:

  + We're using an accessor here: g_settings_get_boolean(). It would
    have been possible to use g_settings_get() directly:
      g_settings_get (settings, key, "b", &variable);

A few notes:

  + We can get rid of gconf-client.h in one file!

It's not used via the gconf API, so we only need the basename now.

We've now get rid of gconf for this part of the code.

g_settings_bind() lets us bind a key from GSettings to the property of
an object. In this example, we bind a boolean key to the visibility of a
widget. Note that this lets us remove some non-interesting code.

A few notes:

  + g_settings_bind() is able to map between the usual types (since a
    value in GSettings has a GVariantType and the property has a GType).
    So for most standard cases, it just works. If this is not enough,
    g_settings_bind_with_mapping() can be used to specify functions to
    do the mapping.

We use the gsettings-schema-convert tool to convert the gconf schema to
a gsetting schema.

A few notes:

  + The --schema-id argument is used to specify the schema ID that will
    be used in the schema. The best practice is to name your file like
    in this example (org.gnome.baobab.gschema) and, in this case, use
    org.gnome.baobab as schema ID.

  + In complex cases, the generated schema will contain FIXME, so make
    sure to check this.

  + After installing the gsettings schema, gschema-compile has to be
    called.

To have a smooth migration for the code, we want to have GSettings and
gconf coexist during the port. There's a GSettings backend that uses
gconf for storage. This makes it possible to have one part of the code
using GSettings while still allowing another part of the code to use
gconf for the same key.

A few notes:

  + This backend is only available in gconf >= 2.31.1.

  + This should be removed once the port is over and migration to the
    default GSettings backend is ready.

  + GSettings won't work unless there's a schema installed for the
    settings that will get accessed.

Add explicit linking to -lm. Fix bug #609934, patch by Matthias Clasen.