Re: panel gconf changes

[Havoc Pennington <hp redhat com>]

"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