My original idea was basically to take the gconf-peditor widgets and make them GtkBuildable, saving a lot of wasted effort. I was going to do some other stuff to make GConf more bearable as well. By the time I started coding, this had become ignoring GConf entirely (which is on its way out sooner than I realised) and essentially closing bug 494329, and related work.
So here are the various things I have written over the last few months:
I added a pretty printer for GVariant objects, which is now in the main gvariant branch of glib.
My Gtk+ branch can read the following:
and later on, you can call gtk_builder_bind_settings_full (...) and it will call a function for each of these bound properties. To avoid a GSettings dependency, nothing happens automatically yet: you have to pass g_settings_bind as the callback.
<object class="GtkCheckButton" id="foo"> <property name="active" setting="foo">true</property> ...
I have a branch with some small changes to GSettings, such as loading schemas from outside the system schemas database. My main contribution is that I just wrote a windows registry backend, with .. wait for it ... full change notification support. So hopefully (I haven't actually tried this in the real world, but it works in my tests) you can update your app's UI as the user edits the settings in regedit and crazy nonsense like that.
(This is all done just with Windows API functions - which is smart enough to tell you a registry has changed, but not smart enough to tell you what value it was, or do so asynchronously. So the code currently caches the settings in memory and works out what has changed the hard way. A month ago I wouldn't have predicted even that to be possible :)
Some of my stuff is still in its own repo at the moment. Here we have g_settings_bind() and an (incomplete) GtkBuildable version of GSettingsList. There is also a script which will read a GtkBuilder file and output a GSettings schema, based on which object properties are bound. Given that you will always need a settings schema, code to control the settings and code that is controlled by the settings, this seems like the best way to minimise duplication of effort; the default values are taken from the default values in the ui. Another option would be to generate the schema from the properties of the object it controls, but this is left as an exercise for now ...
Finally, so people can actually use this stuff easily, I did some GLADE hacking. This branch has a simple GladeSettingsEditor dialog which can edit property bindings .. and even has some incomplete GtkSettingsList editing. Although the dialog works fine, it needs some more stupidity checks; at the moment for example you can bind checkbutton.active and set a related action at the same time.
Thanks to ryan for sorting me out all the time, and also to tristan for help on the GLADE side, and to everyone who spends time making GNOME rock