Re: Module proposal: dconf [migration from gconf]

[Alexander Larsson <alexl redhat com>]

On Thu, 2009-10-22 at 16:38 +0200, Alexander Larsson wrote:
> On Thu, 2009-10-22 at 14:23 +0100, Sam Thursfield wrote:

> > > We want to both be able to read all keys as per the current user, and
> > > determine whether a gconf key really has been set or if it has inherited
> > > the default value (so we don't force all the defaults to be set in the
> > > new dconf store). Also, we should probably have some helper functions to
> > > migrate chunks of the tree in a simple fashion, maybe with a simple
> > > description of how to convert some keynames. This could be shipped in
> > > the GSettings API if its generic enough, or otherwise as a small
> > > cut-and-pasted module.
> > 
> > From "helper functions to migrate chunks of the tree in a simple
> > fashion, maybe with a simple description of how to convert some
> > keynames" it wouldn't be a big step to create a seperate tool to
> > import key data into dconf, which would read an application-provided
> > "map" on 'make install' or package postinstall and do the conversion
> > then.
> 
> This requires all conversion to be specifyable with simple mappings,
> rather than more generic code, which is not always the case with complex
> configuration. Furthermore, doing this at install time is not possible,
> as you might need to convert users settings that are not even accessible
> (i.e. using non-mounted NFS homedirs or whatnot).
> 
> However, it would be possible to have such a tool that can be spawned by
> the app when the user runs it to do the conversion. Not sure if its
> better than accessing gconf via a GSettings API though.

Actually, thinking more on this this seems like the ideal path for most
applications. We ship as part of the platform a executable tool that
links copies from gconf into dconf the set keys for the user as
specified by some xml mapping that lets you do things like:
* copy subtrees
* rename keys
* skip keys
* convert to new types
etc.

Then each app ship with such an xml file and if some app specific dconf
key is unset at startup and (say) ~/.gconf exists then we spawn the
executable with the right arguments.

This lets us convert things to gconf on an application by application
basis while still using shared code to do so and getting a resulting
application that doesn't link to gconf.

For applications that need to do weird conversions where we can't extend
the tool to do this in a generic fashion we could just ship a special
tool with the application that links to gconf so that the normal app
doesn't have to link to gconf.