GSettings and you, II
I have just released GLib 2.25.2 and GConf 2.31.2. These release contain the accumulated bug-fixes that came out of the early adoption after my .1 releases earlier this week. Overall, things should be pretty solid now, so if you hesitated to jump last time, now is an even better time. Some noteworthy changes: - There is now an AM_GSETTINGS autoconf macro similar to AM_GCONF_SOURCE_2 - The .pc variables for schema compilation have changed (but you should really use the AM_GSETTINGS macro anyay) - We install a 'gsettings' utility that gives you commandline access to your settings, similar to gconftool-2 - Robustness and correctness fixes in gsettings-schema-convert and gschema-compile - gsettings-data-convert expects its keyfiles in /usr/share/GConf/gsettings now Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
On Thu, 2010-04-22 at 09:27 -0400, Matthias Clasen wrote: On Thu, Apr 22, 2010 at 8:03 AM, Rodrigo Moya rodr...@gnome-db.org wrote: On Tue, 2010-04-20 at 11:04 -0400, Matthias Clasen wrote: On Tue, Apr 20, 2010 at 10:50 AM, Xavier Claessens xclae...@gmail.com wrote: Nice. Just a question: where can I find the code for the Several fully functional backends? Especially the gconf one. The gconf backend is included in GConf 2.31.1. GLib 2.25.1 includes a memory backend, a keyfile backend and a 'null' backend. and how do you write/install/setup other backends? I see you must implement the GSettingsBackend class, but how can you set it up so that all calls to gsettings_* API use it? Via the env var? To write your own backend (which I don't think you really want to do...), you implement GSettingsBackend. To use, you can either bind it to a special context (similar to what I explained for the keyfile backend), via g_settings_backend_setup (blah, backend) Or you can make your backend implement the gsettings-backend extension point (and possibly build it as a GIO module and install it in /usr/lib/gio/modules). If you do that, GSettings will consider your backend like any other when looking for the default. And you can influence the choice of the default backend by setting the GSETTINGS_BACKEND env var. that's what I'd prefer, since my backend would be a couchdb-based one, so you could just choose it as default and get all settings synchronized to other couchdb instances. Thanks for the info, but I'm sure I'll keep asking more questions on IRC :D ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you, II
В Fri, 23 Apr 2010 06:52:07 -0400, Matthias Clasen написа: - There is now an AM_GSETTINGS autoconf macro similar to AM_GCONF_SOURCE_2 This is a good opportunity to stop abusing Automake's macro namespace, which unfortunately many GNOME-related macros have been doing for years. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you, II
On Fri, 2010-04-23 at 11:54 +, Yavor Doganov wrote: В Fri, 23 Apr 2010 06:52:07 -0400, Matthias Clasen написа: - There is now an AM_GSETTINGS autoconf macro similar to AM_GCONF_SOURCE_2 This is a good opportunity to stop abusing Automake's macro namespace, which unfortunately many GNOME-related macros have been doing for years. What do you recommend replacing it with? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you, II
В Fri, 23 Apr 2010 13:23:56 +0100, Bastien Nocera написа: This is a good opportunity to stop abusing Automake's macro namespace, What do you recommend replacing it with? GLIB_GSETTINGS seems natural, as the glib package is the owner of the macro. (You can use AU_DEFUN to facilitate upgrades for the few packages that already use AM_GSETTINGS). Likewise, GTK_ is a good prefix for GTK+ macros, and GNOME_ is a good prefix for generic GNOME macros (that are currently in gnome-common and/or provided by libraries in the desktop suite). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you, II
On Fri, 2010-04-23 at 06:52 -0400, Matthias Clasen wrote: I have just released GLib 2.25.2 and GConf 2.31.2. These release contain the accumulated bug-fixes that came out of the early adoption after my .1 releases earlier this week. Overall, things should be pretty solid now, so if you hesitated to jump last time, now is an even better time. Some noteworthy changes: snip - gsettings-data-convert expects its keyfiles in /usr/share/GConf/gsettings now I still have a major problem with the backend selection in GSettings. If we were to run gsettings-data-convert on start-up, it would migrate from GConf to GSettings' keyfile backend. I would actually want GConf to GConf migration in this case, because I renamed the key. The backend selection is also completely broken if one were to use plugins from different applications. For example, gnome-bluetooth's wizard has plugins for application integration. Amongst those are a NetworkManager plugin, and a geoclue one. If one of those used GSettings with the gconf backend and the other GSettings with another backend, we'd have a real problem. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you, II
On 04/23/2010 07:54 AM, Yavor Doganov wrote: В Fri, 23 Apr 2010 06:52:07 -0400, Matthias Clasen написа: - There is now an AM_GSETTINGS autoconf macro similar to AM_GCONF_SOURCE_2 This is a good opportunity to stop abusing Automake's macro namespace, which unfortunately many GNOME-related macros have been doing for years. Was just going to point this out. GLIB_GSETTINGS sounds right. Or maybe we should just have a GLIB_INIT([settings introspection ...]) kind of macro? Or, humm, what is the macro supposed to do again? behdad ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you, II
2010/4/23 Yavor Doganov ya...@gnu.org: В Fri, 23 Apr 2010 13:23:56 +0100, Bastien Nocera написа: This is a good opportunity to stop abusing Automake's macro namespace, What do you recommend replacing it with? GLIB_GSETTINGS seems natural, as the glib package is the owner of the macro. (You can use AU_DEFUN to facilitate upgrades for the few packages that already use AM_GSETTINGS). Bug and patch submitted here: [1] [1] https://bugzilla.gnome.org/show_bug.cgi?id=616648 -- Javier Jardón Cabezas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
On Tue, 2010-04-20 at 11:04 -0400, Matthias Clasen wrote: On Tue, Apr 20, 2010 at 10:50 AM, Xavier Claessens xclae...@gmail.com wrote: Nice. Just a question: where can I find the code for the Several fully functional backends? Especially the gconf one. The gconf backend is included in GConf 2.31.1. GLib 2.25.1 includes a memory backend, a keyfile backend and a 'null' backend. and how do you write/install/setup other backends? I see you must implement the GSettingsBackend class, but how can you set it up so that all calls to gsettings_* API use it? Via the env var? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
On Thu, Apr 22, 2010 at 8:03 AM, Rodrigo Moya rodr...@gnome-db.org wrote: On Tue, 2010-04-20 at 11:04 -0400, Matthias Clasen wrote: On Tue, Apr 20, 2010 at 10:50 AM, Xavier Claessens xclae...@gmail.com wrote: Nice. Just a question: where can I find the code for the Several fully functional backends? Especially the gconf one. The gconf backend is included in GConf 2.31.1. GLib 2.25.1 includes a memory backend, a keyfile backend and a 'null' backend. and how do you write/install/setup other backends? I see you must implement the GSettingsBackend class, but how can you set it up so that all calls to gsettings_* API use it? Via the env var? To write your own backend (which I don't think you really want to do...), you implement GSettingsBackend. To use, you can either bind it to a special context (similar to what I explained for the keyfile backend), via g_settings_backend_setup (blah, backend) Or you can make your backend implement the gsettings-backend extension point (and possibly build it as a GIO module and install it in /usr/lib/gio/modules). If you do that, GSettings will consider your backend like any other when looking for the default. And you can influence the choice of the default backend by setting the GSETTINGS_BACKEND env var. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
On 20 April 2010 15:45, Bastien Nocera had...@hadess.net wrote:
GSettings. Here are a couple of notes (in addition to some questions
from Richard who was porting gnome-color-manager):
Some more questions:
1. The Gio /usr/lib/pkgconfig/gio-2.0.pc file has this:
giomoduledir=${libdir}/gio/modules
gsettingsschemadir=${prefix}/share/glib-2.0/schemas
And yet when you do:
pkg-config --variable gsettingsschemadir gio-2.0
you get:
/usr/share/glib-2.0/schemas
(i.e. the ${prefix} is substituted out, rather than being left to the
configure to substitute itself with the correct value)
This breaks make distcheck pretty hard. I fixed this with a bodge:
diff --git a/configure.ac b/configure.ac
index 6eba889..7d7b8de 100644
--- a/configure.ac
+++ b/configure.ac
@@ -171,7 +171,7 @@ fi
AC_PATH_PROG(GCONFTOOL, gconftool-2)
AM_GCONF_SOURCE_2
AC_SUBST(gsettingsschemadir,
- `pkg-config --variable gsettingsschemadir gio-2.0`)
+ `cat /usr/lib/pkgconfig/gio-2.0.pc | grep gsettingsschemadir |
cut -d= -f2`)
AC_SUBST(gsettingsupdateschemacache,
`pkg-config --variable gsettingsupdateschemacache gio-2.0`)
Although we obviously need a cleaner solution than that.
2. When I do make install, I get this:
make[3]: Entering directory `/home/hughsie/Code/gnome-color-manager/data'
/usr/bin/gschema-compile --allow-any-name
/home/hughsie/.root/share/glib-2.0/schemas
Unknown option --allow-any-name
make[3]: *** [install-data-hook] Error 1
I think somebody has to cherry-pick this commit from gsettings-new to
git master.
commit 9970c6854a3e9ba12deeb9fa9ba83113bf3617d4
Author: Matthias Clasen mcla...@redhat.com
Date: Fri Apr 16 12:53:33 2010 -0400
Add an --allow-any-name option
This will make it easier for people to keep their GConf key names
in the transition period.
Ideas, thanks.
Richard.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
On 04/21/2010 04:26 AM, Richard Hughes wrote:
1. The Gio /usr/lib/pkgconfig/gio-2.0.pc file has this:
giomoduledir=${libdir}/gio/modules
gsettingsschemadir=${prefix}/share/glib-2.0/schemas
And yet when you do:
pkg-config --variable gsettingsschemadir gio-2.0
you get:
/usr/share/glib-2.0/schemas
(i.e. the ${prefix} is substituted out, rather than being left to the
configure to substitute itself with the correct value)
Nope, the ${prefix} is replaced with the ${prefix} defined in the same .pc
file. Ie. you install schemas to where gio-2.0.pc thinks you should, not to
the prefix you are installing your package to. I can see why that's not
desirable though. Perhaps we should simply not use the variable from .pc
file? Got to ask, what's the designed use case for that variable?
This breaks make distcheck pretty hard. I fixed this with a bodge:
How does it break make distcheck though? I can only imagine it breaking
make install with non-root.
IIRC I saw a similar issue with gobject-introspection gir files.
behdad
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
On 21 April 2010 09:42, Behdad Esfahbod beh...@behdad.org wrote: How does it break make distcheck though? I can only imagine it breaking make install with non-root. make distcheck ... test -z /usr/share/glib-2.0/schemas || /bin/mkdir -p /usr/share/glib-2.0/schemas /usr/bin/install -c -m 644 org.gnome.ColorManager.gschema.xml '/usr/share/glib-2.0/schemas' /usr/bin/install: cannot create regular file `/usr/share/glib-2.0/schemas/org.gnome.ColorManager.gschema.xml': Permission denied make[4]: *** [install-gsettingsschemaDATA] Error 1 I assume it's not respecting DESTDIR. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
On 04/21/2010 05:10 AM, Richard Hughes wrote: On 21 April 2010 09:42, Behdad Esfahbod beh...@behdad.org wrote: How does it break make distcheck though? I can only imagine it breaking make install with non-root. make distcheck ... test -z /usr/share/glib-2.0/schemas || /bin/mkdir -p /usr/share/glib-2.0/schemas /usr/bin/install -c -m 644 org.gnome.ColorManager.gschema.xml '/usr/share/glib-2.0/schemas' /usr/bin/install: cannot create regular file `/usr/share/glib-2.0/schemas/org.gnome.ColorManager.gschema.xml': Permission denied make[4]: *** [install-gsettingsschemaDATA] Error 1 I assume it's not respecting DESTDIR. Looks like it, yes. behdad Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
On 21 April 2010 09:26, Richard Hughes hughsi...@gmail.com wrote: Although we obviously need a cleaner solution than that. I've just done: diff --git a/configure.ac b/configure.ac --- a/configure.ac +++ b/configure.ac @@ -170,8 +170,6 @@ fi AC_PATH_PROG(GCONFTOOL, gconftool-2) AM_GCONF_SOURCE_2 -AC_SUBST(gsettingsschemadir, - `pkg-config --variable gsettingsschemadir gio-2.0`) AC_SUBST(gsettingsupdateschemacache, `pkg-config --variable gsettingsupdateschemacache gio-2.0`) diff --git a/data/Makefile.am b/data/Makefile.am --- a/data/Makefile.am +++ b/data/Makefile.am @@ -29,6 +29,7 @@ $(service_DATA): $(service_in_files) Makefile @sed -e s|\...@servicedir\@|$(bindir)| $ $@ gsettingsschema_DATA = org.gnome.ColorManager.gschema.xml +gsettingsschemadir = $(datadir)/glib-2.0/schemas org.gnome.ColorManager.gschema.xml: gnome-color-manager.schemas gsettings-schema-convert --force --gconf --xml --schema-id $(@:.gschema=) $ -o $@ # --allow-any-name should be removed once the move from gconf is complete And this seems to work just fine. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
On 21 April 2010 09:26, Richard Hughes hughsi...@gmail.com wrote: On 20 April 2010 15:45, Bastien Nocera had...@hadess.net wrote: GSettings. Here are a couple of notes (in addition to some questions from Richard who was porting gnome-color-manager): Some more questions: For gnome-packagekit and gnome-power-manager we currently do a DBus call to set the default or mandatory values of some keys for all users (which in turn uses PolicyKit for authorization). How do we do this with GSettings? I've not seen any API in the code to do this, although the docs state Both have a concept of mandatory values, which lets you implement lock-down which leads me to think that it should be possible. Thanks, Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
On Wed, 2010-04-21 at 10:48 +0100, Richard Hughes wrote: On 21 April 2010 09:26, Richard Hughes hughsi...@gmail.com wrote: Although we obviously need a cleaner solution than that. I've just done: diff --git a/configure.ac b/configure.ac --- a/configure.ac +++ b/configure.ac @@ -170,8 +170,6 @@ fi AC_PATH_PROG(GCONFTOOL, gconftool-2) AM_GCONF_SOURCE_2 -AC_SUBST(gsettingsschemadir, - `pkg-config --variable gsettingsschemadir gio-2.0`) AC_SUBST(gsettingsupdateschemacache, `pkg-config --variable gsettingsupdateschemacache gio-2.0`) diff --git a/data/Makefile.am b/data/Makefile.am --- a/data/Makefile.am +++ b/data/Makefile.am @@ -29,6 +29,7 @@ $(service_DATA): $(service_in_files) Makefile @sed -e s|\...@servicedir\@|$(bindir)| $ $@ gsettingsschema_DATA = org.gnome.ColorManager.gschema.xml +gsettingsschemadir = $(datadir)/glib-2.0/schemas org.gnome.ColorManager.gschema.xml: gnome-color-manager.schemas gsettings-schema-convert --force --gconf --xml --schema-id $(@:.gschema=) $ -o $@ # --allow-any-name should be removed once the move from gconf is complete And this seems to work just fine. It's wrong if your glib is installed in a prefix different from the one you're installing your application to, just like GConf was broken if you didn't install your app in the same prefix as GConf. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
On Wed, Apr 21, 2010 at 4:26 AM, Richard Hughes hughsi...@gmail.com wrote:
On 20 April 2010 15:45, Bastien Nocera had...@hadess.net wrote:
GSettings. Here are a couple of notes (in addition to some questions
from Richard who was porting gnome-color-manager):
Some more questions:
1. The Gio /usr/lib/pkgconfig/gio-2.0.pc file has this:
giomoduledir=${libdir}/gio/modules
gsettingsschemadir=${prefix}/share/glib-2.0/schemas
And yet when you do:
pkg-config --variable gsettingsschemadir gio-2.0
you get:
/usr/share/glib-2.0/schemas
(i.e. the ${prefix} is substituted out, rather than being left to the
configure to substitute itself with the correct value)
This breaks make distcheck pretty hard.
This is gio telling you where it will look for installed schemas, so
not expanding prefix would not make any sense. You should certainly
prepend $DESTDIR. But, since gsettings is using XDG_DATA_DIRS anyway,
we should probably scrap the variable altogether and just
use $DESTDIR$(prefix)/glib-2.0/schemas. It is then up to people to set
XDG_DATA_DIRS matching that prefix at runtime.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
On Wed, 2010-04-21 at 09:20 -0400, Matthias Clasen wrote:
On Wed, Apr 21, 2010 at 4:26 AM, Richard Hughes hughsi...@gmail.com wrote:
On 20 April 2010 15:45, Bastien Nocera had...@hadess.net wrote:
GSettings. Here are a couple of notes (in addition to some questions
from Richard who was porting gnome-color-manager):
Some more questions:
1. The Gio /usr/lib/pkgconfig/gio-2.0.pc file has this:
giomoduledir=${libdir}/gio/modules
gsettingsschemadir=${prefix}/share/glib-2.0/schemas
And yet when you do:
pkg-config --variable gsettingsschemadir gio-2.0
you get:
/usr/share/glib-2.0/schemas
(i.e. the ${prefix} is substituted out, rather than being left to the
configure to substitute itself with the correct value)
This breaks make distcheck pretty hard.
This is gio telling you where it will look for installed schemas, so
not expanding prefix would not make any sense. You should certainly
prepend $DESTDIR. But, since gsettings is using XDG_DATA_DIRS anyway,
we should probably scrap the variable altogether and just
use $DESTDIR$(prefix)/glib-2.0/schemas. It is then up to people to set
XDG_DATA_DIRS matching that prefix at runtime.
Yes please. This is the same kind of distcheck breaking that we
had with ScrollKeeper. It's why we have --disable-scrollkeeper
in gnome-doc-utils, and why every module has this:
DISTCHECK_CONFIGURE_FLAGS = --disable-scrollkeeper
I assumed from the pkg-config variable that GSettings only looked
in the single directory. But since it's using XDG_DATA_DIRS, we
should just have packages install to glib-2.0/schemas in their
own datadir. If people want to use wonky prefixes, they have to
set XDG_DATA_DIRS. They have to do it already anyway for a bunch
of other things to work.
--
Shaun
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
On Wed, 2010-04-21 at 10:23 -0500, Shaun McCance wrote:
On Wed, 2010-04-21 at 09:20 -0400, Matthias Clasen wrote:
On Wed, Apr 21, 2010 at 4:26 AM, Richard Hughes hughsi...@gmail.com wrote:
On 20 April 2010 15:45, Bastien Nocera had...@hadess.net wrote:
GSettings. Here are a couple of notes (in addition to some questions
from Richard who was porting gnome-color-manager):
Some more questions:
1. The Gio /usr/lib/pkgconfig/gio-2.0.pc file has this:
giomoduledir=${libdir}/gio/modules
gsettingsschemadir=${prefix}/share/glib-2.0/schemas
And yet when you do:
pkg-config --variable gsettingsschemadir gio-2.0
you get:
/usr/share/glib-2.0/schemas
(i.e. the ${prefix} is substituted out, rather than being left to the
configure to substitute itself with the correct value)
This breaks make distcheck pretty hard.
This is gio telling you where it will look for installed schemas, so
not expanding prefix would not make any sense. You should certainly
prepend $DESTDIR. But, since gsettings is using XDG_DATA_DIRS anyway,
we should probably scrap the variable altogether and just
use $DESTDIR$(prefix)/glib-2.0/schemas. It is then up to people to set
XDG_DATA_DIRS matching that prefix at runtime.
Yes please. This is the same kind of distcheck breaking that we
had with ScrollKeeper. It's why we have --disable-scrollkeeper
in gnome-doc-utils, and why every module has this:
DISTCHECK_CONFIGURE_FLAGS = --disable-scrollkeeper
I assumed from the pkg-config variable that GSettings only looked
in the single directory. But since it's using XDG_DATA_DIRS, we
should just have packages install to glib-2.0/schemas in their
own datadir. If people want to use wonky prefixes, they have to
set XDG_DATA_DIRS. They have to do it already anyway for a bunch
of other things to work.
This is now what we're doing in the pkg-config file, and in the examples
in the migration guide.
Note AM_GSETTINGS in configure which will do most of the work for you.
Cheers
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
On Tue, 2010-04-20 at 11:04 -0400, Matthias Clasen wrote: On Tue, Apr 20, 2010 at 10:50 AM, Xavier Claessens xclae...@gmail.com wrote: Nice. Just a question: where can I find the code for the Several fully functional backends? Especially the gconf one. The gconf backend is included in GConf 2.31.1. GLib 2.25.1 includes a memory backend, a keyfile backend and a 'null' backend. How do I use the keyfile backend? 'export GSETTINGS_BACKEND=keyfile' gives me this: Can't find GSettings backend 'keyfile' given in GSETTINGS_BACKEND environment variable I don't have anything under $libdir/gio/modules. Did I miss something? -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
On Wed, Apr 21, 2010 at 6:04 PM, Shaun McCance How do I use the keyfile backend? 'export GSETTINGS_BACKEND=keyfile' gives me this: Can't find GSettings backend 'keyfile' given in GSETTINGS_BACKEND environment variable I don't have anything under $libdir/gio/modules. Did I miss something? The keyfile backend is built in, that is why it doesn't show up in the modules dir. But it is not really meant to be used in that 'global' fashion by setting the env var. Instead, you can use it for selected schemas, by doing the following: g_settings_backend_setup_keyfile (blah, filename); settings = g_settings_new_with_context (org.bla.bla, blah); After that, settings that you get or set with that settings object will be backed by the keyfile named filename. Note that you still need to have an installed schema for org.bla.bla. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
On Wed, Apr 21, 2010 at 3:24 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On Wed, Apr 21, 2010 at 6:04 PM, Shaun McCance How do I use the keyfile backend? 'export GSETTINGS_BACKEND=keyfile' gives me this: Can't find GSettings backend 'keyfile' given in GSETTINGS_BACKEND environment variable I don't have anything under $libdir/gio/modules. Did I miss something? The keyfile backend is built in, that is why it doesn't show up in the modules dir. But it is not really meant to be used in that 'global' fashion by setting the env var. Instead, you can use it for selected schemas, by doing the following: g_settings_backend_setup_keyfile (blah, filename); settings = g_settings_new_with_context (org.bla.bla, blah); After that, settings that you get or set with that settings object will be backed by the keyfile named filename. Note that you still need to have an installed schema for org.bla.bla. Is the intent of the keyfile backend (at least, in a typical GNOME desktop) to have us store application state separate from settings? Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
On Wed, 2010-04-21 at 15:31 -0700, Sandy Armstrong wrote: On Wed, Apr 21, 2010 at 3:24 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On Wed, Apr 21, 2010 at 6:04 PM, Shaun McCance How do I use the keyfile backend? 'export GSETTINGS_BACKEND=keyfile' gives me this: Can't find GSettings backend 'keyfile' given in GSETTINGS_BACKEND environment variable I don't have anything under $libdir/gio/modules. Did I miss something? The keyfile backend is built in, that is why it doesn't show up in the modules dir. But it is not really meant to be used in that 'global' fashion by setting the env var. Instead, you can use it for selected schemas, by doing the following: g_settings_backend_setup_keyfile (blah, filename); settings = g_settings_new_with_context (org.bla.bla, blah); After that, settings that you get or set with that settings object will be backed by the keyfile named filename. Note that you still need to have an installed schema for org.bla.bla. Is the intent of the keyfile backend (at least, in a typical GNOME desktop) to have us store application state separate from settings? My guess is that it would be there as a fallback when neither GConf, nor dconf are available, for barebones command-line applications for example. One good question though, will we have to keep the setenv() hacks in the future, or will GSettings grow knowledge of the priority of the different backends? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
On Wed, 2010-04-21 at 18:24 -0400, Matthias Clasen wrote:
On Wed, Apr 21, 2010 at 6:04 PM, Shaun McCance
How do I use the keyfile backend? 'export GSETTINGS_BACKEND=keyfile'
gives me this:
Can't find GSettings backend 'keyfile' given in GSETTINGS_BACKEND
environment variable
I don't have anything under $libdir/gio/modules. Did I miss something?
The keyfile backend is built in, that is why it doesn't show up in the
modules dir. But it is not really meant to be used in that 'global'
fashion by setting the env var. Instead, you can use it for selected
schemas, by doing the following:
g_settings_backend_setup_keyfile (blah, filename);
settings = g_settings_new_with_context (org.bla.bla, blah);
After that, settings that you get or set with that settings object
will be backed by the keyfile named filename. Note that you still need
to have an installed schema for org.bla.bla.
Ah, thanks for the clarification. For Yelp 3, I'm not
particularly worried about GConf compatibility, but I
do want it to work outside of GNOME. So I'd like it to
use the keyfile backend if GNOME (or something else)
isn't providing a backend.
Is this the sane thing to do then?
if (g_getenv (GSETTINGS_BACKEND))
settings = g_settings_new (org.gnome.yelp);
else {
g_settings_backend_setup_keyfile (blah, filename);
settings = g_settings_new_with_context (org.gnome.yelp, blah);
}
--
Shaun McCance
http://syllogist.net/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
On Wed, Apr 21, 2010 at 7:11 PM, Shaun McCance sha...@gnome.org wrote:
Is this the sane thing to do then?
if (g_getenv (GSETTINGS_BACKEND))
settings = g_settings_new (org.gnome.yelp);
else {
g_settings_backend_setup_keyfile (blah, filename);
settings = g_settings_new_with_context (org.gnome.yelp, blah);
}
No. You are not expected to set GSETTINGS_BACKEND normally. GSettings
picks a default backend based on priorities.
GSETTINGS_BACKEND=gconf is just a hack to ease initial porting, until
dconf is here.
I don't think dconf is something to be afraid of or avoid for fear of
gnome dependencies. We had this with gconf, don't perpetuate this
stupidity by trying to avoid dconf before it is even here.
If people don't want to use yelp because it uses dconf, you probably
don't want them as users anyway...
Matthias
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GSettings and you
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. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
Nice. Just a question: where can I find the code for the Several fully functional backends? Especially the gconf one. Thanks, Xavier Claessens. Le 20/04/10 15:30, Matthias Clasen a écrit : 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. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
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
Re: GSettings and you
On Tue, Apr 20, 2010 at 10:50 AM, Xavier Claessens xclae...@gmail.com wrote: Nice. Just a question: where can I find the code for the Several fully functional backends? Especially the gconf one. The gconf backend is included in GConf 2.31.1. GLib 2.25.1 includes a memory backend, a keyfile backend and a 'null' backend. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
On Tue, 2010-04-20 at 11:03 -0400, Matthias Clasen wrote: 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. 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
Re: GSettings and you
Il giorno mar, 20/04/2010 alle 15.45 +0100, Bastien Nocera ha scritto: - Should the summary and descriptions in the schemas follow the same rules as GConf wrt periods at the end of sentences? About this topic, * while converting from GConf to GSettings, could be good check labels and phrases used in descriptions too, in order to make them simple (when the current phrase is bad, of course) to understand an translate * currently the short descs are short and without periods, long descs are verbose and with periods; the period is the unique element that helps translator to discriminate ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
On Tue, Apr 20, 2010 at 11:04:22AM -0400, Matthias Clasen wrote: On Tue, Apr 20, 2010 at 10:50 AM, Xavier Claessens xclae...@gmail.com wrote: Nice. Just a question: where can I find the code for the Several fully functional backends? Especially the gconf one. The gconf backend is included in GConf 2.31.1. GLib 2.25.1 includes a memory backend, a keyfile backend and a 'null' backend. Any prospect of a win32-registry backend on the horizon? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
On Tue, Apr 20, 2010 at 10:52 PM, Jody Goldberg j...@gnome.org wrote: On Tue, Apr 20, 2010 at 11:04:22AM -0400, Matthias Clasen wrote: On Tue, Apr 20, 2010 at 10:50 AM, Xavier Claessens xclae...@gmail.com wrote: Nice. Just a question: where can I find the code for the Several fully functional backends? Especially the gconf one. The gconf backend is included in GConf 2.31.1. GLib 2.25.1 includes a memory backend, a keyfile backend and a 'null' backend. Any prospect of a win32-registry backend on the horizon? I wrote one last year during soc. It's at http://gitorious.org/gsettings-gtk/gsettings It's undoubtedly well out of date, I haven't touched the code for months. I'll have time to bring it up to scratch early next month, unless someone else fancies the task. sam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
