Re: desktop schemas review [was: Re: GSettings migration status]

[Philip Withnall <philip tecnocode co uk>]

On Sat, 2010-07-03 at 19:48 +0200, Christian Persch wrote:
> Hi;
> 
> Am Sat, 03 Jul 2010 17:08:36 +0200
> schrieb Milan Bouchet-Valat <nalimilan club fr>:
> > Le samedi 03 juillet 2010 à 13:37 +0200, Christian Persch a écrit :
> > > Coincidentally, taking a look at all the <summary> and <description>
> > > strings, it seems to me that once these value enumerations are taken
> > > out, not too much remains that justifies the split between two
> > > strings. IMHO we should consider dropping <summary> from gschema
> > > and only provide for the one <description> strings.
> > In the case of these schemas, I think you're right, but in general
> > the split is really needed. Consider for example this Metacity key,
> > which is only one example among many others:
> >     <key name="resize-with-right-button" type="b">
> >       <default>false</default>
> >       <summary>Whether to resize with the right button</summary>
> >       <description>
> >         Set this to true to resize with the right button and show a
> > menu with the middle button while holding down the key given in
> >         "mouse-button-modifier"; set it to false to make it work
> >         the opposite way around.
> >        </description>
> >     </key>
> > 
> > If only one string was provided, it would be a pain to find what a key
> > is supposed to do without reading the full description. And that's
> > what makes the settings database more useful than a mere addition of
> > binary values (for example, if we want a « plumbing tool » to tweak
> > advanced settings, we need it to have short and useful summaries).
> 
> Makes sense. We should at least discourage schema writers from making
> the description just a reworded summary.
> 
> Or, let's only have the one <description> string, and take the first
> line (paragraph?) of it as the "summary", and any extra text as detail
> that will only be displayed in a tooltip, 'detailed info' area, etc.
> 
> Like we do for our git commit messages :)

Isn't that somewhat betraying the idea of XML as a _structured_
representation of data?

Philip