| <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| <html> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> |
| <title>Conceptual differences: GIO Reference Manual</title> |
| <meta name="generator" content="DocBook XSL Stylesheets V1.79.1"> |
| <link rel="home" href="index.html" title="GIO Reference Manual"> |
| <link rel="up" href="ch34.html" title="Migrating from GConf to GSettings"> |
| <link rel="prev" href="ch34.html" title="Migrating from GConf to GSettings"> |
| <link rel="next" href="ch34s03.html" title="GConfClient (and GConfBridge) API conversion"> |
| <meta name="generator" content="GTK-Doc V1.25.1 (XML mode)"> |
| <link rel="stylesheet" href="style.css" type="text/css"> |
| </head> |
| <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> |
| <table class="navigation" id="top" width="100%" summary="Navigation header" cellpadding="2" cellspacing="5"><tr valign="middle"> |
| <td width="100%" align="left" class="shortcuts"></td> |
| <td><a accesskey="h" href="index.html"><img src="home.png" width="16" height="16" border="0" alt="Home"></a></td> |
| <td><a accesskey="u" href="ch34.html"><img src="up.png" width="16" height="16" border="0" alt="Up"></a></td> |
| <td><a accesskey="p" href="ch34.html"><img src="left.png" width="16" height="16" border="0" alt="Prev"></a></td> |
| <td><a accesskey="n" href="ch34s03.html"><img src="right.png" width="16" height="16" border="0" alt="Next"></a></td> |
| </tr></table> |
| <div class="section"> |
| <div class="titlepage"><div><div><h2 class="title" style="clear: both"> |
| <a name="id-1.5.4.3"></a>Conceptual differences</h2></div></div></div> |
| <p> |
| Conceptually, GConf and GSettings are fairly similar. Both |
| have a concept of pluggable backends. Both keep information |
| about keys and their types in schemas. Both have a concept of |
| mandatory values, which lets you implement lock-down. |
| </p> |
| <p> |
| There are some differences in the approach to schemas. GConf |
| installs the schemas into the database and has API to handle |
| schema information (<code class="function">gconf_client_get_default_from_schema()</code>, |
| <code class="function">gconf_value_get_schema()</code>, etc). GSettings on the other hand |
| assumes that an application knows its own schemas, and does |
| not provide API to handle schema information at runtime. |
| GSettings is also more strict about requiring a schema whenever |
| you want to read or write a key. To deal with more free-form |
| information that would appear in schema-less entries in GConf, |
| GSettings allows for schemas to be 'relocatable'. |
| </p> |
| <p> |
| 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. |
| </p> |
| </div> |
| <div class="footer"> |
| <hr>Generated by GTK-Doc V1.25.1</div> |
| </body> |
| </html> |
