Re: panel gconf changes
- From: Havoc Pennington <hp redhat com>
- To: "Kevin Vandersloot" <kfv101 psu edu>
- Cc: Mark McLoughlin <mark skynet ie>, <desktop-devel-list gnome org>
- Subject: Re: panel gconf changes
- Date: 22 Mar 2002 10:59:58 -0500
"Kevin Vandersloot" <kfv101 psu edu> writes:
> Hi Mark. Shouldn't gconf handle this properly on make install,
> instead of requiring the user to delete schemas files manually? It
> would seem insane that every time a schemas file is changed, the
> user has to delete the old one.
>
This kind of change would never happen post-stable-release. However
it's the price of running betas. ;-)
We need a policy on schema changes post-stable-release. I believe that
policy (from a high level) is essentially:
- config keys must be backward AND FORWARD compatible
- what this means is that if I log in from two places,
using two versions of GNOME, with the same gconf
database, then nothing should break
- to allow us to make changes that enhance the
desktop, we do allow that if you are logged in
using two versions, you may need to configure
"the same" thing twice, once per version.
Of course it's best to avoid this.
The simplest way to _implement_ those guidelines:
- if you in any way change the set of possible values
of a config key, or how those values are
interpreted, you must rename the config key
- if you don't rename the config key you can't add
new possible values. the main case in which
this will be painful is for "enum" config keys,
where you add a new enum value in the code
and have to change the schemas accordingly.
If you rename a config key due to a change in possible values, you
could have your app copy the old key to the new key on startup, for
the case where the new key is unset. However it would be wrong to
delete the old key here (because the user may still use old versions
of GNOME simultaneously). You should only create the new key.
I need to write up a good overview doc on gconf, including these
guidelines, guidelines on designing schemas, and some common FAQs.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]