Re: GSettings and you

[Matthias Clasen <matthias clasen gmail com>]

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.

> - 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 !

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

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

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

I'll add something.

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

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

> - How come no g_settings_get_float, only g_settings_get_double?

Because dbus (and thus gvariant) only has doubles.

> - "/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 ?

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

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

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

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

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

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


Thanks for trying this out!