On Tue, Apr 20, 2010 at 10:45 AM, Bastien Nocera <had...@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! _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list