2 <title>Migrating from GConf to GSettings</title>
5 <title>Before you start</title>
8 Converting individual applications and their settings from GConf to
9 GSettings can be done at will. But desktop-wide settings like font or
10 theme settings often have consumers in multiple modules. Therefore,
11 some consideration has to go into making sure that all users of a setting
12 are converted to GSettings at the same time or that the program
13 responsible for configuring that setting continues to update the value in
17 It is always a good idea to have a look at how others have handled
18 similar problems before. An examplaric conversion can be found e.g.
19 in the <ulink url="http://git.gnome.org/browse/gnome-utils/log/?h=gsettings-tutorial">gsettings-tutorial</ulink> branch of gnome-utils.
24 <title>Conceptual differences</title>
27 Conceptually, GConf and GSettings are fairly similar. Both
28 have a concept of pluggable backends. Both keep information
29 about keys and their types in schemas. Both have a concept of
30 mandatory values, which lets you implement lock-down.
33 There are some differences in the approach to schemas. GConf
34 installs the schemas into the database and has API to handle
35 schema information (gconf_client_get_default_from_schema(),
36 gconf_value_get_schema(), etc). GSettings on the other hand
37 assumes that an application knows its own schemas, and does
38 not provide API to handle schema information at runtime.
39 GSettings is also more strict about requiring a schema whenever
40 you want to read or write a key. To deal with more free-form
41 information that would appear in schema-less entries in GConf,
42 GSettings allows for schemas to be 'relocatable'.
45 One difference in the way applications interact with their
46 settings is that with GConf you interact with a tree of
47 settings (ie the keys you pass to functions when reading
48 or writing values are actually paths with the actual name
49 of the key as the last element. With GSettings, you create
50 a GSettings object which has an implicit prefix that determines
51 where the settings get stored in the global tree of settings,
52 but the keys you pass when reading or writing values are just
53 the key names, not the full path.
58 <title>GConfClient (and GConfBridge) API conversion</title>
61 Most people use GConf via the high-level #GConfClient API.
62 The corresponding API is the #GSettings object. While not
63 every GConfClient function has a direct GSettings equivalent,
65 <table id="gconf-client-vs-gsettings">
68 <row><entry>GConfClient</entry><entry>GSettings</entry></row>
71 <row><entry>gconf_client_get_default()</entry><entry>no direct equivalent,
72 instead you call g_settings_new() for the schemas you use</entry></row>
73 <row><entry>gconf_client_set()</entry><entry>g_settings_set()</entry></row>
74 <row><entry>gconf_client_get()</entry><entry>g_settings_get()</entry></row>
75 <row><entry>gconf_client_get_bool()</entry><entry>g_settings_get_boolean()</entry></row>
76 <row><entry>gconf_client_set_bool()</entry><entry>g_settings_set_boolean()</entry></row>
77 <row><entry>gconf_client_get_int()</entry><entry>g_settings_get_int()</entry></row>
78 <row><entry>gconf_client_set_int()</entry><entry>g_settings_set_int()</entry></row>
79 <row><entry>gconf_client_get_float()</entry><entry>g_settings_get_double()</entry></row>
80 <row><entry>gconf_client_set_float()</entry><entry>g_settings_set_double()</entry></row>
81 <row><entry>gconf_client_get_string()</entry><entry>g_settings_get_string()</entry></row>
82 <row><entry>gconf_client_set_string()</entry><entry>g_settings_set_string()</entry></row>
83 <row><entry>gconf_client_get_list()</entry><entry>for string lists, see g_settings_get_strv(), else see g_settings_get_value() and #GVariant API</entry></row>
84 <row><entry>gconf_client_set_list()</entry><entry>for string lists, see g_settings_set_strv(), else see g_settings_set_value() and #GVariant API</entry></row>
85 <row><entry>gconf_entry_get_is_writable()</entry><entry>g_settings_is_writable()</entry></row>
86 <row><entry>gconf_client_notify_add()</entry><entry>not required, the #GSettings::changed signal is emitted automatically</entry></row>
87 <row><entry>gconf_client_add_dir()</entry><entry>not required, each GSettings instance automatically watches all keys in its path</entry></row>
88 <row><entry>#GConfChangeSet</entry><entry>g_settings_delay(), g_settings_apply()</entry></row>
89 <row><entry>gconf_client_get_default_from_schema()</entry><entry>no equivalent, applications are expected to know their schema</entry></row>
90 <row><entry>gconf_client_all_entries()</entry><entry>no equivalent, applications are expected to know their schema, and GSettings does not allow schema-less entries</entry></row>
91 <row><entry>gconf_client_get_without_default()</entry><entry>no equivalent</entry></row>
92 <row><entry>gconf_bridge_bind_property()</entry><entry>g_settings_bind()</entry></row>
93 <row><entry>gconf_bridge_bind_property_full()</entry><entry>g_settings_bind_with_mapping()</entry></row>
99 GConfBridge was a third-party library that used GConf to bind an object property
100 to a particular configuration key. GSettings offers this service itself.
103 There is a pattern that is sometimes used for GConf, where a setting can have
104 explicit 'value A', explicit 'value B' or 'use the system default'. With GConf,
105 'use the system default' is sometimes implemented by unsetting the user value.
108 This is not possible in GSettings, since it does not have API to determine if a value
109 is the default and does not let you unset values. The recommended way (and much
110 clearer) way in which this can be implemented in GSettings is to have a separate
111 'use-system-default' boolean setting.
116 <title>Change notification</title>
119 GConf requires you to call gconf_client_add_dir() and
120 gconf_client_notify_add() to get change notification. With
121 GSettings, this is not necessary; signals get emitted automatically
125 The #GSettings::changed signal is emitted for each changed key.
126 There is also a #GSettings::change-event signal that you can handle
127 if you need to see groups of keys that get changed at the same time.
130 GSettings also notifies you about changes in writability of keys,
131 with the #GSettings::writable-changed signal (and the
132 #GSettings::writable-change-event signal).
136 <section><title>Change sets</title>
138 GConf has a a concept of a set of changes which can be applied or reverted
139 at once: #GConfChangeSet (GConf doesn't actually apply changes atomically,
140 which is one of its shortcomings).
143 Instead of a separate object to represent a change set, GSettings has a
144 'delayed-apply' mode, which can be turned on for a GSettings object by
145 calling g_settings_delay(). In this mode, changes done to the GSettings
146 object are not applied - they are still visible when calling g_settings_get()
147 <emphasis>on the same object</emphasis>, but not to other GSettings instances
148 or even other processes.
151 To apply the pending changes all at once (GSettings <emphasis>does</emphasis>
152 atomicity here), call g_settings_apply(). To revert the pending changes,
153 call g_settings_revert() or just drop the reference to the #GSettings object.
158 <title>Schema conversion</title>
161 If you are porting your application from GConf, most likely you already
162 have a GConf schema. GConf comes with a commandline tool
163 gsettings-schema-convert that can help with the task of converting
164 a GConf schema into an equivalent GSettings schema. The tool is not
165 perfect and may need assistence in some cases.
167 <example><title>An example for using gsettings-schema-convert</title>
168 <para>Running <userinput>gsettings-schema-convert --gconf --xml --schema-id "org.gnome.font-rendering" --output org.gnome.font-rendering.gschema.xml destop_gnome_font_rendering.schemas</userinput> on the following <filename>desktop_gnome_font_rendering.schemas</filename> file:
171 <?xml version="1.0"?>
175 <key>/schemas/desktop/gnome/font_rendering/dpi</key>
176 <applyto>/desktop/gnome/font_rendering/dpi</applyto>
179 <default>96</default>
182 <long>The resolution used for converting font sizes to pixel sizes, in dots per inch.</long>
189 produces a <filename>org.gnome.font-rendering.gschema.xml</filename> file with the following content:
193 <schema id="org.gnome.font-rendering" path="/desktop/gnome/font_rendering/">
194 <key name="dpi" type="i">
195 <default>96</default>
196 <summary>DPI</summary>
197 <description>The resolution used for converting font sizes to pixel sizes, in dots per inch.</description>
207 GSettings schemas are identified at runtime by their id (as specified
208 in the XML source file). It is recommended to use a dotted name as schema
209 id, similar in style to a D-Bus bus name, e.g. "org.gnome.SessionManager".
210 In cases where the settings are general and not specific to one application,
211 the id should not use StudlyCaps, e.g. "org.gnome.font-rendering".
212 The filename used for the XML schema source is immaterial, but
213 schema compiler expects the files to have the extension
214 <filename>.gschema.xml</filename>. It is recommended to simply
215 use the schema id as the filename, followed by this extension,
216 e.g. <filename>org.gnome.SessionManager.gschema.xml</filename>.
220 The XML source file for your GSettings schema needs to get installed
221 into <filename>$datadir/glib-2.0/schemas</filename>, and needs to be
222 compiled into a binary form. At runtime, GSettings looks for compiled
223 schemas in the <filename>glib-2.0/schemas</filename> subdirectories
224 of all <envar>XDG_DATA_DIRS</envar> directories, so if you install
225 your schema in a different location, you need to set the
226 <envar>XDG_DATA_DIRS</envar> environment variable appropriately.
229 Schemas are compiled into binary form by the
230 <link linkend="glib-compile-schemas">glib-compile-schemas</link> utility.
231 GIO provides a <literal>glib_compile_schemas</literal>
232 variable for the schema compiler.
235 You can ignore all of this by using the provided m4 macros. To
236 do this, add to your <filename>configure.ac</filename>:
240 The corresponding <filename>Makefile.am</filename> fragment looks like
243 # gsettings_SCHEMAS is a list of all the schemas you want to install
244 gsettings_SCHEMAS = my.app.gschema.xml
246 # include the appropriate makefile rules for schema handling
252 This is not sufficient on its own. You need to mention what the source
253 of the <filename>my.app.gschema.xml</filename> file is. If the schema
254 file is distributed directly with your project's tarball then a mention
255 in <varname>EXTRA_DIST</varname> is appropriate. If the schema file is
256 generated from another source then you will need the appropriate rule
257 for that, plus probably an item in <varname>EXTRA_DIST</varname> for the
258 source files used by that rule.
262 One possible pitfall in doing schema conversion is that the default
263 values in GSettings schemas are parsed by the #GVariant parser.
264 This means that strings need to include quotes in the XML. Also note
265 that the types are now specified as #GVariant type strings.
269 <default>rgb</default>
275 <key name="rgba-order" type="s">
276 <default>'rgb'</default> <!-- note quotes -->
282 Another possible complication is that GConf specifies full paths
283 for each key, while a GSettings schema has a 'path' attribute that
284 contains the prefix for all the keys in the schema, and individual
285 keys just have a simple name. So
288 <key>/schemas/desktop/gnome/font_rendering/antialiasing</key>
294 <schema id="org.gnome.font" path="/desktop/gnome/font_rendering/">
295 <key name="antialiasing" type="s">
300 Default values can be localized in both GConf and GSettings schemas,
301 but GSettings uses gettext for the localization. You can specify
302 the gettext domain to use in the <tag class="attribute">gettext-domain</tag>
303 attribute. Therefore, when converting localized defaults in GConf,
306 <key>/schemas/apps/my_app/font_size</key>
308 <default>18</default>
311 <default>24</default>
319 <schema id="..." gettext-domain="your-domain">
321 <key name="font-size" type="i">
322 <default l10n="messages" context="font_size">18</default>
328 GSettings uses gettext for translation of default values.
329 The string that is translated is exactly the string that appears
330 inside of the <tag class='starttag'>default</tag> element. This
331 includes the quotation marks that appear around strings.
332 Default values must be marked with the <varname>l10n</varname>
333 attribute in the <tag class='starttag'>default</tag> tag, which
334 should be set as equal to <literal>'messages'</literal> or
335 <literal>'time'</literal> depending on the desired category. An
336 optional translation context can also be specified with the
337 <varname>context</varname> attribute, as in the example. This
338 is usually recommended, since the string "<literal>18</literal>"
339 is not particularly easy to translate without context. The
340 translated version of the default value should be stored in the
341 specified <varname>gettext-domain</varname>. Care must be taken
342 during translation to ensure that all translated values remain
343 syntactically valid; mistakes here will cause runtime errors.
346 GSettings schemas have optional <tag class="starttag">summary</tag> and
347 <tag class="starttag">description</tag> elements for each key which
348 correspond to the <tag class="starttag">short</tag> and
349 <tag class="starttag">long</tag> elements in the GConf schema and
350 will be used in similar ways by a future gsettings-editor, so you
351 should use the same conventions for them: The summary is just a short
352 label with no punctuation, the description can be one or more complete
353 sentences. If multiple paragraphs are desired for the description, the
354 paragraphs should be separated by a completely empty line.
357 Translations for these strings will also be handled
358 via gettext, so you should arrange for these strings to be
359 extracted into your gettext catalog. One way to do that is to use
360 intltool. For that, you use <tag class="starttag">_summary</tag>
361 and <tag class="starttag">_description</tag> elements in a
362 .gschema.xml.in file and use
363 <literal>@<!-- -->INTLTOOL_XML_NOMERGE_RULE<!-- -->@</literal>
364 in your Makefile.am to produce the .gschema.xml file. The
365 <literal>NOMERGE</literal> part of the rule instructs intltool
366 to extract translatable strings, but not merge the translations
367 back into the generated xml file.
370 GSettings is a bit more restrictive about key names than GConf. Key
371 names in GSettings can be at most 32 characters long, and must only
372 consist of lowercase characters, numbers and dashes, with no
373 consecutive dashes. The first character must not be a number or dash,
374 and the last character cannot be '-'.
377 If you are using the GConf backend for GSettings during the
378 transition, you may want to keep your key names the same they
379 were in GConf, so that existing settings in the users GConf
380 database are preserved. You can achieve this by using the
381 <option>--allow-any-name</option> with the
382 <link linkend="glib-compile-schemas">glib-compile-schemas</link> schema
383 compiler. Note that this option is only meant
384 to ease the process of porting your application, allowing parts
385 of your application to continue to access GConf and parts to use
386 GSettings. By the time you have finished porting your application
387 you must ensure that all key names are valid.
391 <section><title>Data conversion</title>
393 GConf comes with a GSettings backend that can be used to
394 facility the transition to the GSettings API until you are
395 ready to make the jump to a different backend (most likely
396 dconf). To use it, you need to set the <envar>GSETTINGS_BACKEND</envar>
397 to 'gconf', e.g. by using
399 g_setenv ("GSETTINGS_BACKEND", "gconf", TRUE);
401 early on in your program. Note that this backend is meant purely
402 as a transition tool, and should not be used in production.
405 GConf also comes with a utility called
406 <command>gsettings-data-convert</command>, which is designed to help
407 with the task of migrating user settings from GConf into another
408 GSettings backend. It can be run manually, but it is designed to be
409 executed automatically, every time a user logs in. It keeps track of
410 the data migrations that it has already done, and it is harmless to
411 run it more than once.
414 To make use of this utility, you must install a keyfile in the
415 directory <filename>/usr/share/GConf/gsettings</filename> which
416 lists the GSettings keys and GConf paths to map to each other, for
417 each schema that you want to migrate user data for.
424 antialiasing = /desktop/gnome/font_rendering/antialiasing
425 dpi = /desktop/gnome/font_rendering/dpi
426 hinting = /desktop/gnome/font_rendering/hinting
427 rgba-order = /desktop/gnome/font_rendering/rgba_order
429 [apps.myapp:/path/to/myapps/]
430 some-odd-key1 = /apps/myapp/some_ODD-key1
433 The last key demonstrates that it may be necessary to modify the key
434 name to comply with stricter GSettings key name rules. Of course,
435 that means your application must use the new key names when looking
436 up settings in GSettings.
439 The last group in the example also shows how to handle the case
440 of 'relocatable' schemas, which don't have a fixed path. You can
441 specify the path to use in the group name, separated by a colon.
444 There are some limitations: <command>gsettings-data-convert</command>
445 does not do any transformation of the values. And it does not handle
446 complex GConf types other than lists of strings or integers.
449 Don't forget to require GConf 2.31.1 or newer in your configure
450 script if you are making use of the GConf backend or the conversion
455 If, as an application developer, you are interested in manually
456 ensuring that <command>gsettings-data-convert</command> has been
457 invoked (for example, to deal with the case where the user is
458 logged in during a distribution upgrade or for non-XDG desktop
459 environments which do not run the command as an autostart) you
460 may invoke it manually during your program initialisation. This
461 is not recommended for all application authors -- it is your
462 choice if this use case concerns you enough.
465 Internally, <command>gsettings-data-convert</command> uses a
466 keyfile to track which settings have been migrated. The
467 following code fragment will check that keyfile to see if your
468 data conversion script has been run yet and, if not, will
469 attempt to invoke the tool to run it. You should adapt it to
470 your application as you see fit.
476 ensure_migrated (const gchar *name)
478 gboolean needed = TRUE;
483 kf = g_key_file_new ();
485 g_key_file_load_from_data_dirs (kf, "gsettings-data-convert",
486 NULL, G_KEY_FILE_NONE, NULL);
487 list = g_key_file_get_string_list (kf, "State", "converted", &n, NULL);
491 for (i = 0; i < n; i++)
492 if (strcmp (list[i], name) == 0)
501 g_key_file_free (kf);
504 g_spawn_command_line_sync ("gsettings-data-convert",
505 NULL, NULL, NULL, NULL);
512 Although there is the possibility that the
513 <command>gsettings-data-convert</command> script will end up
514 running multiple times concurrently with this approach, it is
515 believed that this is safe.