On Mon, 2009-10-05 at 16:01 +0200, Frédéric Péters wrote:
> It's already six months ago that you wrote:
> 
> > The rewrite of dconf is currently extremely unstable and incomplete,

dconf is currently stable and reasonably complete for simple uses.
There have been two releases and there will likely be a third release
tomorrow or Thursday.

There are many outstanding issues, documented here:

https://bugzilla.gnome.org/buglist.cgi?product=dconf

I am making progress on these issues.  The largest issue is probably the
NFS one.  It will be a short while before it's ready, but I promise that
the solution that I'm thinking up for it will be extremely awesome. :)

> We at the release team will decide in November if 2.30 will be 3.0,
> and I noticed you pushed a gsettings branch for Devhelp, so I thought
> it was well time for a status update :)

Interesting to see that this is still an open question. :)

> Some specific questions I have:
> 
>  * do you plan to port another app? as Devhelp had its own abstraction
>    layer over gconf it's not straightforward for other applications to
>    just look at what you did in Devhelp. Porting a straight GConf user
>    would be quite useful IMHO.

Yes.  I do.  Devhelp was just an obvious choice because it was fairly
simple (in terms of preferences) and I use it a lot.  I didn't realise
until after I started hacking about the abstraction layer.

> * what's the status of inclusion in glib? what are the showstoppers?

This is sticky and complicated.  There are about 4 issues here and I
will give you my best estimation of each:

1) GSettings lives in gio/.  Alex is responsible for that, of course,
and he seems quite excited about the project.  I know he has done some
light review of the code but nothing very serious yet.  He knows the
architecture and he likes the big-picture design.

2) I recently added support for binding GObject properties to GSettings
keys.  This, of course, involves the ability to convert values between
the DBus type system and GValue.  I very recently added code to do this
to gobject/ in order to allow new GTypes to register conversion
functions for themselves (so you can bind to a property of any type --
the base types are already implemented).  Presumably Tim would be
responsible for reviewing that code but I have made no contact yet.

This code is optional in two senses.  First, the bind call could be
removed entirely (although I don't favour that).  Second, the bind call
could be hard-coded to only deal with basic types (bools, ints, floats,
strings) in which case no additional support code in gobject/ would be
required.  This basic support could be expanded to the full support in
the future.

3) GSettings and any backend for GSettings (including dconf itself)
depend very heavily on GVariant.  GVariant is currently on the
'gsettings' branch of glib in glib/.  This is under the authority of
Matthias and he has expressed misgivings about it.  I've asked him a
couple of times exactly what his objections were and he hasn't given
definite answers.  One time I think he told me that he'd write a mail to
me, but I don't remember receiving it.  I am going to talk with him at
Boston face to face.

This is really a serious problem.  If GVariant can't be in libglib then
GSettings can't be in libgio (since GSettings depends on GVariant very
deeply).  Both could be released in a separate tarball, but that's
really missing the point for two reasons.  One: with GSettings outside
of glib, GTK would be unable to use it.  Two: other possible users of
GVariant (like GBus) are screwed unless GSettings is installed.

4) There are some small outstanding bugs filed against glib (at least
one I can think of: #548967) that are required for GVariant to work.  I
haven't been able to get much love on these bugs so I've gone ahead and
merged them into the GSettings branch in the meantime.  Even if a
separate GSettings/GVariant tarball were to be released [which is a
route I'd like to avoid] these bugs would still need to be addressed.  I
will probably remember some of the others as I try to make a tarball. :)

>  * did you identify modules that will be harder to port, because they
>    use gconf in more extensive ways (I am thinking of tools such as
>    gconf-editor or sabayon) ?

I have a dconf-editor that is extremely basic.  Unfortunately, I haven't
given any thought to tools like Sabayon yet.

> Feel free to blog the answer as there are many interested people
> besides me :)

We're going to have a big chat at Boston and I'll blog after that.
Hopefully this is enough information to update the release team in the
meantime.

Thanks for asking :)

Cheers