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

[Christian Persch <chpe gnome org>]

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 :)

> > Looks like this should use a settings list, with a base schema
> > containing "exec", "needs-term" (should be "needs-terminal" as
> > below) keys, and an extended schema for the browser settings adding
> > the "nremote" key.
> I've considered this too when reading the file, but in the end I was
> really not sure we gain anything with a list. GSettingsList is
> intended for schemas that will be extended at runtime, while here we
> have a list that is mostly set in stone. Apps only look for a known
> schema, and will never want to get the list of all registered
> applications, nor add an application to the list.
> 
> So I don't think that's worth the complexity it would add

I don't think it adds complexity, but reduces it. You only need to
write the schema once, and then can just reference it and override its
values (this is not in gsettings yet, but I think it's going to land
soon?).

Regards,
	Christian