Comments on: Hacking local defaults into GConf

By: Owen

Owen — Wed, 10 Jun 2009 12:28:39 +0000

Hmm, changing the path for gconfd isn’t really an option, since we are using the user’s normal gconfd from the enclosing session.

Though maybe an option would be to patch libgconf to allow an extra of local sources to read *after* querying the engine:

export GCONF_FALLBACK_SOURCES=xml:readonly:$(HOME)/gnome-shell/install/etc/gconf/gconf.xml.defaults

Then we could add GConf to the jhbuild, and schema installation would go into the local directory (because we’re using the locally build gconftool), and we could set the environment variable.

Certainly cleaner than my approach. The main disadvantage I see is that we couldn’t work with both gconf-dbus and normal gconf, since we’d have to jhbuild one or the other. Are any Linux distros using gconf-dbus?

By: Ray Strode

Ray Strode — Tue, 09 Jun 2009 18:54:34 +0000

Another idea might be to just add a $GCONF_SOURCE_PATH_FILE environment variable that points to a file in your jhbuild install root (say ~/gnome-shell/install/etc/gnome-shell/gconf-path) which has something like:

# pull from jhbuild gconf config source for schemas
xml:readonly:$(HOME)/gnome-shell/install/etc/gconf/gconf.xml.defaults

# but use system gconf database for settings
include /etc/gconf/2/path

Would require a small patch to gconf though to check $GCONF_SOURCE_PATH_FILE before trying GCONF_CONFDIR/path though.

By: Owen

Owen — Mon, 08 Jun 2009 11:24:57 +0000

Using a separate session makes a lot of sense for running a nested environment. But ‘gnome-shell –replace’ replaces the user’s existing window manager, and should integrate with logout, the screensaver, etc, so it’s probably not to applicable for us. (Or for someone just JHBuilding a single application.) There are maybe also potential synchronization problems if you have two gconfd’s both writing to the same user database?

By: Tomeu Vizoso

Tomeu Vizoso — Mon, 08 Jun 2009 10:20:18 +0000

Don’t know how much applicable is this to GNOME Shell, but in Sugar we are launching the shell inside a new session bus. As we are using GConf D-BUS, we don’t have the issue you are seeing.