two notes on gsettings

1: the gsettings hackfest is on. april 12 – 17 in cambridge mass. see for more information. the goal is to get gsettings stable and merged into glib and to port some of the big desktop applications to it (panel, nautilus, evolution, etc). walking away from this hackfest we should be in a spot where it is reasonable for other applications to port themselves.

2: gvariant (the type system on which dconf, gsettings, gdbus and other things are based) is almost entirely merged into glib. only one small part (parsing of text values) is outstanding. all other functionality is there as it will be in the next glib stable release. if you’re a present user of gvariant from the branch then please take a look at the master branch and make sure everything is as you expected — if you don’t say anything then this is what will become the official API.

i also did my first release of glib today (including the latest gvariant goodness). i think that was a good thing, although now i’m starting to have second thoughts…

12:24 <bratsche> desrt: Are you maintaining glib now or something?
12:25 <desrt> bratsche: no.  just helping a little.
12:25 <mclasen> bratsche: psst, he doesn't know yet

i just returned from boston summit. boston summit is always scheduled on canadian thanksgiving which usually means that i can’t attend, but this year i bit the bullet.

i’m glad i did.

the three days of the conference were perhaps the three most productive days i have spent at any event. the entire attendence was on the order of about 30-40 people. this allowed the format to be very informal, and the level of focus allowed by that was fantastic.

for me, one of the happiest things to report is that i had a “hallway track” talk with davidz, mclasen and wjt. a very nice conclusion came from this talk. the upshot of that conversion is that the following items are all likely to occur:

  • GVariant will be included in the next stable release of glib
  • GDBus will be included in the next stable release of glib
  • GDBus will be modified to be based on GVariant

already, davidz has ported GDBus to GVariant and he reports that it’s working very nicely. you can see that work in the gdbus-standalone git repository.

while in boston, i proposed dconf as a new module for GNOME 2.30. reception on d-d-l has been very positive. this means that the following two points are also likely:

  • GSettings will be included in the next stable release of glib
  • dconf will ship with GNOME 3.0

a couple of other things that really stuck out for me from the summit:

gnome-shell: it seemed to me that the number of people using gnome-shell on their laptops increased substantially over the course of the summit. i’ve personally switched over to using it full-time. it’s weird and a little bit strange, but there are some things about it that i really like. i’ve also been showing it to some “normal humans” since coming back and they think that it’s pretty cool too.

splinter: in case you haven’t heard, we now have patch review integrated into GNOME bugzilla. click the “review” button beside the patch. kudos to owen for this.

that’s all for this post. i have a couple of new projects that i’m working on as a result of the summit that i will talk about soon.

“be excellent to each other”

it’s perhaps a bug in the ubuntu code of conduct that it does not include something that we can find elsewhere — in the KDE code of conduct.

i believe that “be excellent to each other” very much includes “assume that people mean well”.

i’m personally a bit tired of seeing people repeatedly publicly flogged for an innocent action (where i define innocent as “very obviously without malice”).

ps: can we please get back to work? boston summit just ended today and i can tell you that there is certainly no lack of actual interesting things to be spending time on.

edit: thanks to murray for pointing out that the “assume people mean well” language appears also in the GNOME code of conduct. KDE just had better google juice for the term :)

maybe this saves you some time

if you want to install seed on your ubuntu jaunty system and you are looking for a version of webkit that is sufficiently recent to work with seed, is sufficiently old enough that it doesn’t require you to install a new libsoup and sufficiently unbroken enough to actually compile, then i have a number for you: revision 45557.

that is all :)


21:56 <@hub> desrt: the yet another rewrite of Evo IMAP... more bugs for less features
21:56 * hub wonder why they didn't use Tinymail instead
21:57 <@desrt> i'd like to take a moment to declare that i love pvanhoof
21:58 <@desrt> not for any particular piece of software that he has written; just 'cause.
21:58 <@hub> desrt: I dare you to post that on pgo

some nice gnio facts

here’s a post to go with my last post about gsettings.

there’s really only one nice fact to mention about gnio:

it’s in glib now. go get it. use it.

huge thanks are due, of course, to alex and danw for all the hard work and attention in tweaking the api and merging.

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.


hello everyone

many of you know that i’ve been working on gnio for a little while. it is available from git://

gnio is a networking library built on the foundations of gio. it allows you to use network connections as input and output streams.

you need the gresolver branch of glib in order to use it. that’s at git://

i think it’s pretty nice, but i’d like some feedback. if you could take it for a spin and send flames my way, it would be greatly appreciated. i’m specifically looking for API suggestions.

any bugs or feature requests should be filed in the ‘network’ component of glib on bgo. contributions of code, docs, tests are most welcome and i encourage you to attach git-format-patch output to the relevant bugs.

thanks :)


currently on the plane on the way back home from uds. it’s been a pretty great week, but i’m glad to be getting home.

first thing: props to canonical. when i was checking out of the hotel the guy at the desk said something to the effect of “and canonical has everything covered”. that stuck with me.

earlier this year i was considering a job with canonical. it turns out that my interests were more aligned with work elsewhere and i ended up working for codethink. despite being employed elsewhere, canonical still invited me to uds. when you take a step back to consider that, you really realise that we live in a special sort of world. “normal companies” don’t tend to do things like that.

in any case, twice a year canonical flies a bunch of us out for this awesome event that they put on. this year i also attended fosscamp. for both events, the gnome group, as usual, spent a good deal of time on the hallway track getting things done.

a few hilights from this week:

notifications: by the end of the week many of us were refering to uds as “nbs: notification bikeshed summit”. in a way, it was a little bit demotivating to spend so much time talking on this subject. on thursday, however, christian hammond drove up to the googleplex from vmware and we all had a sitdown meeting. we came to a good compromise and — even better, as a result of the compromise — canonical’s changes are going upstream this cycle. in the end, i think this ended up being a pretty big win. also: awesome to see that rob carr is back. during uds he wrote what is probably the most awesome patch ever.

trash: i rewrote the gvfs trash backend and committed it to trunk on thursday. awalton (cool hacker who i met for the first time) is working on some associated UI changes to nautilus. seb will be rolling a jaunty package shortly after he arrives home. please try to break it — you know where to send the hatemail. :)

gnio: downloaded and started poking at gnio, which is a library to do networking in a way similar to gio (using the same stream abstractions, etc). started hacking on it a bit. christian and i are aiming to have this included in gio during this cycle (ie: by guadec time).

gritty: jono had one of the first sessions of fosscamp. his idea is that we’d have a lot more experimentation with the development of cool new software if it wasn’t so damned difficult to get your hacks on to other people’s machines. lowering the barrier to distribution would encourage people to share ideas. early exposure to users will encourage hackers to develop their ideas into proper projects. mvo and i have started hacking on a prototype for how this might work. gritty is a name chosen at random by mvo picking a number and me going to that line in /usr/share/dict/words (+/- about 10 lines… “groans” wasn’t such a good name). with any luck we can have a first version of this in jaunty.

in non-uds/fosscamp news, i’ve also heard word from rob that work on dconf will be starting within the next couple of weeks.

after a week, i am returning home with excitement and a renewed focus. i have a whole lot of projects that i’m pretty excited about.

time to start hacking!