some nice gsettings facts

i haven’t written about gsettings in a while. i’ve been working on it a lot though. i will now write about a couple of nice things that gsettings will do for you.

many backends
you can have many backends for gsettings. dconf is merely one of them. the backends are local to the process, so you can have (for example, and already implemented) a keyfile backend that reads/writes .ini directly from the process or a backend that just stores the settings temporarily in memory.

settings and notification without a mainloop
gsettings makes all change notifications from the context of the _set() call that caused them. this means that if you are using a gsettings backend that never receives external events (like the temporary memory example) then you don’t need a mainloop at all.

no blocking, no async
gsettings (and dconf) were carefully designed from the start so that gsettings calls will simultaneously never block and never require async completion callbacks. in the case of using gsettings with the dconf backend, all reads are read directly from the memory-mapped settings database — so no blocking here.

writes, of course, have to go through the dconf service, so things are a little more tricky. when you do a _set() call the call is sent as a async dbus call. as mentioned above, a change notification is generated immediately from context of the _set() call. the value that you set is temporarily locally cached so that _get() calls before the dbus call complete will get this value directly. if the dbus call comes back affirmatively then the local cached copy is forgotten (since it is now in the database). if the dbus call comes back indicating an error (which really should be quite exceptional) then the local cached copy is forgotten -and- an additional change notification is emitted. to the programmer this gives the appearance that the change occurred successfully but then was reverted back to its original value by someone outside the program. this is consistent and provides a very simple to use interface that never blocks. this particular setup does require a mainloop.

of course, a great feature of this setup is that the dconf service can fsync() to its heart’s content without ever blocking an application’s user interface. rather nicely side-steps that whole debate, i say.

support for lists
gsettings has native support for lists of settings — things like accounts or gnome-terminal profiles. a GSettingsList object will keep track of the settings items in the list and you get nice “added” and “removed” signals when things change. if a GSettings item is part of a list then you also get a “destroyed” signal on that object itself (and its children) if it is ever removed from the list.

delayed apply
it is possible to create a ‘delayed apply’ gsettings object. when you modify this gsettings object, all the changes you make are instantly visible to yourself (ie: you can query it again to see the updated value) but are not written to the database (or even visible to other gsettings objects in your program) until you call apply(). this allows for having your settings object consistent with your preferences dialog box until «apply» is clicked.

support for GTK
a GSettingsList can be used with GtkTreeView. all the hard work of implementing GtkTreeModel has been done for you. in the near future i even plan to add support for making it very easy to create dialogs with «add» «remove» and «modify» buttons for lists of items. also (currently written in vala and being ported to C today) is a simple GSettingsDialog class which subclasses GtkDialog and tracks a GSettings object. if the settings is destroyed the dialog is destroyed with it. if the settings is delayed-apply then an «apply» button is automatically added (and wired up and set sensitive as appropriate). my summer of code student, sam thursfield, is currently investigating ways to improve the creation of these preferences dialog boxes. with any luck, writing code for simple preferences dialogs may be a thing of the past.

currently some evil hacks are used so that if gsettings detects that it is linked with libgtk then additional functionality is enabled (ie: using dlsym() to implement GtkTreeModel). after today there will be a separate libgsettings-ui and eventually (hopefully) these features will merge into GTK itself.

a release is coming soon.