Re: GSettings and you

[Bastien Nocera <hadess hadess net>]

On Tue, 2010-04-20 at 09:00 -0400, Matthias Clasen wrote:
> Hey,
> 
> with the GLib 2.25.1 and GConf 2.31.1 releases that I've made
> yesterday, the results of last weeks GSettings hackfest are now
> available.
> 
> Some pieces of the puzzle are still missing:
> 
>  - Dconf is still being worked on
> 
>  - Support for lists of settings (like a lists of accounts, or
> /desktop/gnome/url-handlers) is not there yet
> 
>  - The handling of enums is not very convenient yet
> 
> 
> But we have more than enough in place now to let you start porting applications:
> 
> - Several fully functional backends
> 
>  - API documentation: http://library.gnome.org/devel/gio/2.25/settings.html
> 
>  - Man pages: http://library.gnome.org/devel/gio/2.25/tools.html
> 
>  - A porting guide: http://library.gnome.org/devel/gio/2.25/ch23.html
> 
>  - An example: http://git.gnome.org/browse/gnome-utils/log/?h=gsettings-tutorial
> 
> Playing around with what we have now would be very helpful for
> discovering the (undoubtedly existing) oversights and omissions in the
> GSettings API. We recommend to use the GConf backend (see the
> gnome-utils example for how to do that) until dconf is ready for prime
> time.
> 
> So, the race is on for the first release of a GSettings-based application.

Tried to port gnome-bluetooth and its single GConf preference to
GSettings. Here are a couple of notes (in addition to some questions
from Richard who was porting gnome-color-manager):
- 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.
- Would be nice to add a chapter in the porting guide about
g_settings_bind() if one used GConfBridge
- Mention that GConf calls in configure.ac should be removed from
compile flags, require checking for GConf >= 2.31.1 still
- 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)
- No best practices for key names and paths (dashes? underscores?
spaces?), or schema names (org.gnome.Bluetooth?
org.gnome.Bluetooth.properties? gnome-bluetooth?)
- No mention of the .gschema.xml suffix for schemas
- mention the g_setenv ("GSETTINGS_BACKEND", "gconf", FALSE); hack
- 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?
- gsettings-schema-convert does not convert underscores to dashes (and
it disallows underscores in key names)
- How come no g_settings_get_float, only g_settings_get_double?
- "/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)
- 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)
- 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)
- 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)
- I needed to use the G_SETTINGS_BIND_NO_SENSITIVITY flag to
g_settings_bind() otherwise it wouldn't know about my key
- /usr/share/gconf/gsettings isn't created by default (either tarball or
the package should)
- 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)

This commit shows my work on gnome-bluetooth so far:
http://git.gnome.org/browse/gnome-bluetooth/commit/?id=2e0a63705df026993f3741c491ce258876dca729

Cheers