Hi everyone! I thought I would write my final SOC report to my blog, so that it gets everyone excited about a really cool new API that you can’t easily use for anything at the moment, but it is going to be awesome when you can!
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:
<object class="GtkCheckButton" id="foo"> <property name="active" setting="foo">true</property> ...
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.
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.
I think this is a reasonable amount of work for 3 or so months .. especially counting the time I wasted on autotools issues and git confusion 🙂 Compared to my original proposal, some big things on the gsettings-ui side are still unfinished .. but I have done some other things not in the proposal at all, so it balances out I guess. The inspiration for this project was the fact that working with GConf sucks, and you end up wasting a lot of time, so I’ll be continuing working on this until I can use it in my apps in place of the GConf API. My future plans include (ignoring the obvious things such as testing and merging into the main repos) supporting flag and enum values in various useful ways, converting some apps which currently have a lot of code dedicated to preferences and replacing it with a much smaller amount of gsettings code (mainly for the satisfaction), and writing a tutorial entitled “How to use GSettings and GTK+ to make your life much easier”