[final report] gsettings-gtk

Hello everyone
I posted a report on what I have done to my blog, which I will
reproduce here for reference:

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:

    * GLib
      I added a pretty printer for GVariant objects, which is now in
the main gvariant branch of glib.

    * GTK+
      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.

    * gsettings
      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 :)

    * gsettings-gtk
      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 ...

    * GLADE
      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"

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]