Hi! On 9 August 2013 16:29, Martyn Russell <mar...@lanedo.com> wrote: > On 08/08/13 14:42, Jonatan Pålsson wrote: >> >> Hi list, > > > Hello Jonatan, > > >> I would like to re-locate the user data directory and user cache. >> Currently these directories are retrieved using g_get_user_data_dir () >> and g_get_user_cache_dir (), which in turn may be affected by the user >> by setting appropriate XDG_* variables. I would however like a more >> persistent setting, so I added the user-cache-dir and user-data-dir >> keys to the org.freedesktop.Tracker.DB namespace in DConf. >> >> The behavior of the two keys is similar. If the key is set, it takes >> precedence over g_get_user_*_dir () and the supplied path is used for >> storing the files. If the key is empty (the default setting), the old >> behavior is preserved. >> >> Please see the following patch: >> >> https://github.com/Pelagicore/tracker-ivi/commit/213456024d686305d0f6a30b09fa81f04e601fdd >> >> I also have a patch for setting the path to the ontology directory. I >> will submit it in a different thread to keep the discussion separate. > > > Can I ask why do you need this sort of patch? > > You can accomplish everything the patch achieves AFAICS by just setting the > $XDG_CACHE_HOME, $XDG_CONFIG_HOME and $XDG_DATA_HOME environment variables > before running any one of the Tracker binaries. In fact, this is what I do > in the script I wrote to have localised Tracker DBs for different datasets. > > I would like to avoid adding more config and maintenance burden to specify > locations. We already have a lot of that. > > Is there some reason the env vars are not enough? >
Yes, the same functionality can be accomplished by using the environment variables already in place. I think the configuration options make it clearer for the user that these values can be changed however. By having the options available in the config, they are easier (in my opinion) to set for users. Previously, with the environment variables, a wrapper script had to be written to accomplish the same thing. Ideally, I would like all available options not set at compile time to be in the config. This would make the config a centralized place for all configuration, and users could inspect it (and also get valuable descriptions for each option if using a graphical configuration tool). Settings can be exported using "dconf dump" and loaded using "dconf load" - which would allow a user to save all settings and restore them at a later point. This only makes sense if all settings are stored in dconf however. We probably have different visions for the config, mine is to make it a central repo for *all* configuration. What is the official stance on what goes in the config and what goes elsewhere? Also, Philip: I have a new set of patches which should fix the issues you showed. I will wait with submitting them until I know whether this idea is at all interesting! :) Thanks to both of you for reviewing the idea & patch! -- Regards, Jonatan Pålsson Pelagicore AB Ekelundsgatan 4, 6th floor, SE-411 18 Gothenburg, Sweden _______________________________________________ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
