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 <[EMAIL PROTECTED]> IRC: smitten _______________________________________________ gnome-doc-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-doc-list
