Re: GSettings and you

[Bastien Nocera <hadess hadess net>]

On Tue, 2010-04-20 at 11:03 -0400, Matthias Clasen wrote:
> On Tue, Apr 20, 2010 at 10:45 AM, Bastien Nocera <hadess hadess net> wrote:
> 
> > - http://library.gnome.org/devel/gio/2.25/ch23s06.html mentions
> > gsettings-schema-convert but not what flags should be used, or examples
> > of what the output would look like, or what it's supposed to look like.
> 
> Ok, I'll flesh that out some more.
> 
> The one flag I think I did mention is --allow-any-name which you
> probably want to use so you can keep the underlines in your key names
> for now, while using the gconf backend.

OK. I went with the "nice key names from the start".

> > - Would be nice to add a chapter in the porting guide about
> > g_settings_bind() if one used GConfBridge
> 
> I don't even know what GConfBridge is, so I am probably not the best
> person to write that. Contributions welcome !

I'll write something up.

> > - Mention that GConf calls in configure.ac should be removed from
> > compile flags, require checking for GConf >= 2.31.1 still
> 
> Good point, will add that.
> 
> > - No mention of what gconf_client_get_default()'s equivalent would be
> > (or what the schema name would be, and how it relates to the filename of
> > the schema installed)
> 
> Ok, I'll try to make that clearer: The filename of the .gschema.xml
> file is immaterial. You pass the id (on the <schema> element in the
> xml) to g_settings_new().

OK. Mentioning that the filename is free-form would be nice, giving some
guidance as to what it should be would be nicer. I used
org.gnome.Bluetooth.gschema.xml for gnome-bluetooth.

> > - No best practices for key names and paths (dashes? underscores?
> > spaces?), or schema names (org.gnome.Bluetooth?
> > org.gnome.Bluetooth.properties? gnome-bluetooth?)
> 
> The idea is to use dotted names for the schema id, and just
> lowercase+dashes for key names (that is mentioned somewhere...).

OK.

> > - No mention of the .gschema.xml suffix for schemas
> > - mention the g_setenv ("GSETTINGS_BACKEND", "gconf", FALSE); hack
> 
> I'll add something.

Thanks.

> > - Should the summary and descriptions in the schemas follow the same
> > rules as GConf wrt periods at the end of sentences?
> > - Should the gschema.xml be translated? With XML merge, or no merge?
> 
> I'll add a section about these topics. Short answer: no merging. We
> use gettext for translation, thats why there's a gettext-domain
> attribute.

I filed a bug against gsettings-schema-convert to include a
gettext-domain by default in the output.

https://bugzilla.gnome.org/show_bug.cgi?id=616309

> > - gsettings-schema-convert does not convert underscores to dashes (and
> > it disallows underscores in key names)
> 
> Vincent wrote that conversion script. I guess he just didn't get
> around to that yet. Patch welcome, I'm sure.  It should probably be an
> explicit --convert-names
> option though, since there is some risk of collisions.

https://bugzilla.gnome.org/show_bug.cgi?id=616310

> > - How come no g_settings_get_float, only g_settings_get_double?
> 
> Because dbus (and thus gvariant) only has doubles.

OK.

> > - "/usr/bin/gschema-compile /usr/share/glib-2.0/schemas" will dump
> > gschemas.compiled in your current directory instead of the schemas dir
> > (Matthias mentions adding "--targetdir=/usr/share/glib-2.0/gsettings" to
> > the command)
> 
> Can you file this as a bug, please ?

https://bugzilla.gnome.org/show_bug.cgi?id=616311

> > - No equivalent to "if GCONF_SCHEMAS_INSTALL" for Makefile.am rules
> > (should be agreed upon and added to a .m4 file, either in gnome-common
> > or glib)
> 
> This is probably a good idea.
> m4 is not exactly my forte, contributions welcome.

glib currently doesn't install any m4 macros. I'd be happy to fix that
problem if we know we want it in glib as opposed to gnome-common.

https://bugzilla.gnome.org/show_bug.cgi?id=616312

> > - Until we have something like gconf-editor for gsettings, would be nice
> > to have a few command-line applications to test things out (such as
> > monitoring keys, dumping the current state, or setting a key)
> 
> Yes, that would be nice.

Filed as:
https://bugzilla.gnome.org/show_bug.cgi?id=616313

> > - The migration guide mentions gsettings-data-convert but doesn't say
> > that it's pretty useless when using the GConf GSettings backend (and the
> > key names stay the same)
> 
> Right. The porting guide kinda ignores the gconf backend, currently.
> I'll set that straight.

Thanks.

> > - I needed to use the G_SETTINGS_BIND_NO_SENSITIVITY flag to
> > g_settings_bind() otherwise it wouldn't know about my key
> 
> Sounds like a bug. Please file it.

The problem is likely with g_settings_is_writable() being wrong. Filed
against GConf:
https://bugzilla.gnome.org/show_bug.cgi?id=616307

> > - /usr/share/gconf/gsettings isn't created by default (either tarball or
> > the package should)
> 
> My packaging bug, I guess. File against GConf2 in Fedora...

Shouldn't an empty directory be created by the Makefile.am anyway?

Filed as:
https://bugzilla.redhat.com/show_bug.cgi?id=584059

> > - I couldn't get the data conversion between GConf and GSettings to work
> > (/apps/bluetooth-manager/show_icon for GConf,
> > and /apps/bluetooth-manager/show-icon for GSettings)
> 
> I'll have a look.

Do you want me to file a bug about it?

show_icon is not getting propagated to "show-icon". "show-icon" changes
state in GConf when the app changes it.

Cheers