Re: Module proposal: dconf
- From: Sam Thursfield <ssssam gmail com>
- To: Johannes <jhs jsschmid de>, desktop-devel-list gnome org
- Subject: Re: Module proposal: dconf
- Date: Sat, 17 Oct 2009 02:41:58 +0100
On Sat, Oct 17, 2009 at 1:09 AM, Johannes <jhs jsschmid de> wrote:
> * It is definitly important to keep the user settings over the
> transition. So at least any setting that is mentioned in a schema file
> has to be migrated (others are buggy, right?). I cannot say how to do
> this but I think it is possible.
>
> I hope the dconf/GSettings guys will come up with some migration
> strategy because the are likely the only ones that know about technical
> details.
I think we need to pay attention to Ryan's comment that the GSettings
conversion should be an opportunity for apps to tidy up their schemas
and use the new features gsettings allows. It's a dead end doing a
blind gconf->gsettings schema conversion: just think about how much
richer a type system gvariant is compared to gconf's, for example. I
know I've committed various hacks around the gconfvalue's limitiations
and I'm sure there are examples in many gnome apps.
With that in mind, the app is going to need a certain amount of
involvement in the migration progress. I suggest that when an app
migrates to gsettings, it provides a mapping in some form of the gconf
schema to the gsettings schema. A tool can read this and migrate any
settings in gconf to dconf when the new version is installed - either
in 'make install' or as a post-install hook in distro packages.
A couple of points about this:
- it needs to flag once it has done the conversion, so that old gconf
settings don't overwrite new dconf settings each time the package is
upgraded.
- the mapping only needs to mention gconf keys that don't have an
obvious analogue in the gsettings schema
- this gives app developers the minimum amount of work while allowing
them to use new gsettings features
Sam
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]