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

Le samedi 03 juillet 2010 à 13:37 +0200, Christian Persch a écrit :
> Hi;
> I think we should use the opportunity of converting to gsettings to
> redesign the desktop schemas, not just do a 1:1 translation from gconf.
> Let me make some remarks about the gsettings desktop schemas as
> they right now are in gsettings-desktop-schemas module.
I agree with most of your suggestions too. Just two remarks.

> 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">
      <summary>Whether to resize with the right button</summary>
        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.

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

> 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]