My gsoc idea, which relates to gconf

Hello. I'd like to discuss the idea I've had for Summer of Code this
year, which i mentioned on gnome-soc-list but realised it would be
better discussed here. Here's an overview of the idea:

Basically using GConf in a standard GNOME application is a lot harder
than it could be, and although there have been various localised
solutions to the problem I think gconf integration needs a few months
of love. Hopefully an example is the best way to explain what I want to ach=
ieve.
Let's say Joe starts work on a revolutionary new GNOME application.
Before long he has some things he'd like to make configurable and
expose to the user. He then has to:

* Hand-write a gconf .schemas file, which is a little annoying
* Perhaps make a header with #define KEY_FOO_BAR
"/apps/my-app-with-a-long-name/foo/bar" etc.
* Write gconf notify hooks to update his application's state.
* Make a dialog with widgets to control these settings, neatly aligned
and indented to match other GNOME apps - it's annoying wrestling with
vbox padding etc. in Glade, or having to modify an existing apps
dialog, when these things normally follow the same pattern.
* Connect all the widgets to the gconf properties - which each project
solves in a different way, some writing a special callback for each
widget, some writing their own code to do so automatically, and it
seems none of them using the 'gconf-bridge' library which I only
discovered this afternoon.

When I'm done, this workflow should hopefully change to:
* Define the keys he wants to use, in format nicer than XML
* Define the dialogs he wants to use, in a simple heirarchical way.
* Write gconf notify hooks to update the application's state.
* Add a macro to his autoconf file, or wscript or whatever he likes to
use, and link to the correct library.


There's a couple of obvious points raised, which I'd like to hear
anyone's comments on.

1. Integration with gconf: it would be nice if this tool & library
could become part of the gconf package rather than introducing yet
another dependency to certain projects. Obviously the portion of the
library which connects to gtk+ can't go in the main gconf library, but
maybe a function to bind to generic properties etc. could do?

2. The schemas format. I don't really like hand-coding XML, and much
prefer making keys that look like this:
=A0 =A0(key "import/file-name-parsing/enable" bool
=A0 =A0 =A0 =A0 =A0 :default true
=A0 =A0 =A0 =A0 =A0 :blurb "Enable file name parsing")
Compare that to the 10 lines of XML it produces in the .schemas file.
However, it seems silly to include a tool with gconf to turn schemas
from one format into another, when gconf could be modified to read the
new format directly. But I have a bad feeling about adding a schemas
format other than XML - I don't know why.

3. I saw a comment last year about how gconf is going stale and we
should wait for something else, like dconf. I'd hope that's not an
issue with regards this project, since
=A0 =A0a) anyone writing an app now, needs to use the gconf API, and will
for the forseeable future, and
=A0 =A0b) The described GSettings API makes almost none of this project
redundant. The dconf site said nothing about the .schemas file format.

And this doesn't have to be in the soc project, but does fit in with
the idea of consolidating code into gconf:
4. A couple of places (libeel, libgames-support) create pointless
wrapper API's which create a global gconf client and then use that, in
preference to calling gconf_client_get_default() each time they want
to call a gconf_* method. Surely this functionality could be merged
into gconf fairly easily?

There's some more info in my post to gnome-soc-list:
http://mail.gnome.org/archives/gnome-soc-list/2009-March/msg00039.html
However, I hope there's some positive response to my idea on this
list. I actually began with the idea of making a new package, but the
more I thought about it the more being part of gconf seemed to make
more sense. Anyway, I'd love to hear the opinions of gconf users and
developers on this project and thanks for taking the time to read this
long mail!

Sam Thursfield