A couple of weeks ago, we updated Tracker to load its configuration using GSettings instead of its own old-fashioned .cfg files. GSettings is an API to manipulate key=value pairs that abstracts the backend (keyfiles, gconf, dconf…) where they are actually stored.
This was a good change in a lot of senses, but it was breaking our functional tests. We have a suite of tests that we like to run once Tracker is installed in the system. They check if the basic functionality is working fine: the store starts, the miner starts, basic Sparql is processed fine, crawling/monitoring a directory is ok… Some of those tests rely on booting tracker with an specific configuration and with gsettings that isn’t as easy as defining a new XDG_CONFIG_DIR anymore. Well, lets fix the tests then.
My first idea was to hack our GSettings object to load data from the system or from a keyfile, depending on an environment variable: very portable, but is an ugly hack and the code paths start to differ a lot. Then i discovered the DConf profiles. Only works when gsettings is using dconf and needs to install a system-wide profile, but otherwise (in code and test setup) is nice.
It took me more time than expected due some stupid mistakes here and there using dconf:
- Profile names can only use alphanumeric and underscore characters. A profile like “tracker-test” won’t work (because is not a valid dbus name), but “trackertest” is fine. (Wiki updated now)
- Do NOT set XDG_CONFIG_DIR in the environment (Bug reported). I guess that the client is using the variable to look for the DB but the writing daemon is not, so the results are not the expected
- If at the same time you are changing the dconf schemas, make sure to remove old files from
/usr/share/glib-2.0/schemas, run/usr/bin/glib-compile-schemas /usr/share/glib-2.0/schemasand remove any old dconf database (in ~/.config/dconf) including “user”. Otherwise if some code is using the old schema, it won’t complain but the values will be wrong. - DConf uses the GVariant serialization, so be careful when setting lists.
I hope this saves some time to the next person trying to test something that uses dconf for its settings.
Interesting Article, Ivan.
I have a question for you. if using Dconf with Gsettings, is it possible to compile out parts that Gnome3 would normally reference on Startup???
my logic here, is that i would like to strip a few things out of the Gnome3 stack, including gnome-panel. So far, by changing the toplevel-id list in gsettings i was able to stop gnome-panel from loading. but ideally i would like to get rid of it, and a few other things as well.
there isn’t a whole lot of info around the net on either gsettings or dconf. I very much appreciate info and links you have provided ~ awesome stuff!
jordan
@MFwR I think gsettings/dconf is not the right place to fine-tune the GNOME booting sequence. Take a look into “/etc/xdg/autostart” directory, maybe you can disable something there.
Yes, I have already looked there. I’ve actually taken a look all through systemd, dconf, gsettings, and the obvious one ~ /etc/xdg/autostart . I had already disabled some other apps from autostart.
it’s not the booting process that is the problem, it is gsettings/dconf having a hiccup because of the current method i am using to kill gnome-panel. – literally, screwing up the keys in dconf that tell gnome-panel how to position itself, when it starts up. – so this causes a delay, and it takes longer for my desktop to actually be usuable.
i’m am almost dead-positive this has to do with dconf/gsettings, but i haven’t been able to find a proper solution, so far.