Re: GConf Key Reference

[Brent Smith <gnome nextreality net>]

Shaun McCance wrote:
> It would be really cool to track what keys were in the previous
> version (and then we'll have to decide which version is the most
> useful to consider "previous") and do some special formatting of
> new and changed keys.

I assume the tarballs from the release-team for the .0 release would be
the best candidate for "previous" version.  Might be useful to compare
latest "stable" releases to the .0 release, but ideally nothing should
change.

> Unfortunately, a lot of cases of backwards-compatibility breaks
> (and forwards-compatibility breaks) just won't be detectable with
> any sort of script that I can think of, and that would be really
> nice data to have.  (Not so that we can adjust for it, but so that
> we know it's time to smack a developer.)

Why wouldn't it be detectable?

We should be able to detect new keys for every distinct "owner", as well
as removed or deleted keys.  We should also be able to detect new
owners, and changes in keys types and default values.  Can't think of
anything else that would change that would break things...

> Joachim's suggestion to use a variable list is good.  Also, the
> default values for string types might be better off in monospace,
> or at least a wide font.  (Damn the web for giving us too much
> font control, but not the sort of font control we really need.)

If I use a variable list, where does the type and default information
go?

> Man, I wish GConf allowed key descriptions to have simple inline
> formatting.  Look at those descriptions in /apps/sound-juicer!

Agreed.  Perhaps we should mention this to Havoc or Mark - the only
affected programs would be those who query and display the short long
descriptions in gconf - so mainly gconf-editor.  I know pessulus also
does this too.  But gconf uses GMarkup, and I'm not sure how that
handles entities < etc.

--
Brent Smith <gnome nextreality net>
IRC: smitten