GNOME Bugzilla – Bug 674803
Use XDG dirs instead of $HOME
Last modified: 2012-04-25 19:04:52 UTC
It would be great if we supported the XDG base directory standard for the settings storage. https://live.gnome.org/GnomeGoals/XDGConfigFolders Currently we store in ~/.gconf It might be fine to do something like: * use .config/gconf if present * use ~/.gconf if present * create and use .config/gconf
so it's a little tricky to add smarts here since the location is hard coded in /etc/gconf/2/path as xml:readwrite:$(HOME)/.gconf We could introduce a $(DEFAULTUSERPATH) that expands to ~/.config/gconf or $(HOME)/.gconf under the hood depending on the logic above I guess and then change the config file to use that new variable
Created attachment 212810 [details] [review] Try to use XDG config directory for settings storage And fallback to the original locations if it isn't found.
One option is to just do the fallback using the existing source mechanisms. I haven't been able to test if this will work yet. Seemed a little cleaner than adding smarts to the daemon though.
if we're going to stack them instead of doing either/or daemon side, we need to investigate the implications of what happens when both exist at the same time.
Created attachment 212811 [details] [review] Try to use XDG config directory for settings storage And fallback to the original locations if it isn't found.
Review of attachment 212811 [details] [review]: i like this a lot better. ::: gconf/default.path.in @@ +16,2 @@ # Now see where users want us to look - basically the user can stick arbitrary +# sources in a ~/.config/gconf.path file and they're inserted here with the exception of a few bad apples ~/.config is almost entirely directories. I think it's a good idea to not put individual files there, but in a subdirectory. @@ +20,2 @@ include "$(HOME)/.gconf.path" so one question is should the legacy path file be read first or last. I think you got it right. if the user has a legacy path file we should prefer it. @@ +24,1 @@ maybe add a (or $(HOME)/.gconf when it exists for backward compatibility) to the comment ::: gconf/gconf-internals.c @@ +703,3 @@ + + path_new = g_build_filename (g_get_user_config_dir (), "gconf", NULL); + path_old = g_build_filename (g_get_user_config_dir (), "gconf", NULL); path_old and path_new are identical here. ::: gconf/gconf.path @@ +4,3 @@ # to be writeable) is used to load/store the data. # You can also use include statements +xml:readwrite:$(USERCONFIGDIR)/gconf why make this different than default.path.in ?
Created attachment 212823 [details] [review] Try to use XDG config directory for settings storage And fallback to the original locations if it isn't found.
Review of attachment 212823 [details] [review]: Seem fine to me. ::: gconf/gconf-internals.c @@ +707,3 @@ + || (! g_file_test (path_old, G_FILE_TEST_IS_DIR))) + { + /* leak the path */ not sure about this comment. the other case of the if also leaks the path, but it doesn't have a comment. duplicate comments would look sloppy, though. I don't think it adds much and would probably just drop it, or move it to where user_source is declared ::: gconf/gconfd.c @@ +404,1 @@ configdir will have backslashes on windows so I wouldn't think g_strconcat would be right, it parallels what was there before so I guess it works.
Committed without the comment.