GNOME Bugzilla – Bug 328679
enhance glib support for xdg basedir spec
Last modified: 2011-12-09 14:19:01 UTC
When reading the XDG basedir spec [1], I think a few more functions in glib will make it easier for applications to comply with the spec. To start with, I suggest adding g_get_data_dirs and g_get_config_dirs that simply return the output of their respective g_get_user_*_dir followed by g_get_system_*_dirs, because that's the main usecase of these directories in the spec. Without these APIs, users will either use g_get_system_*_dirs only, or have to extend their logic to check g_get_user_*_dir before that, something that will be missed most probably. A more detailed API I can think of would have four functions for reading/writing data/config files, and will automatically search in places described in the spec under "Referencing this specification". The problem is that a file interface may not be enough. For example, devhelp needs to go over data dirs and add ./gtk-doc/html and ./devhelp to it's search path. So, one way to handle it is having a foreach api, something like: gchar * g_data_dir_foreach (gchar * (*callback) (gchar *filename, gpointer userdata), gchar *relpath, gpointer userdata); gchar * g_config_dir_foreach (gchar * (*callback) (gchar *filename, gpointer userdata), gchar *relpath, gpointer userdata); where what they do is to call callback, passing to it DIR/relpath for each DIR in the respective list, and stop as soon as the callback returns a non-NULL value, and returns that value. We can then define an stock callbacks too: * One that checks that filename exists and is readable, if yes, returns it. This can be used to find the right configuration/data file. This handles the reading part of the spec completely. For writing, something like this is enough: const gchar* g_user_data_dir (void); const gchar* g_user_config_dir (void); where these will try to create the directory with permission 0700 if it doesn't exist. And return it, or NULL if it faild. Naming can be imroved though. Anyway, I may be overcomplicating implementation of a very short spec. [1] http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
Any progress on this? Sounds rather useful and easy to implement and if this has any chance to go into glib I would implement it.
Can you comment on the proposed API first? It's far from concrete :).
IMHO the proposed API sounds good and would probably make it easier to conform to the spec. But we would also need a g_user_cache_dir(), right? For those g_user_*_dir() functions, why can't we just take g_get_user_*_dir() and just change the behaviour slightly to create the directory if not existing yet? g_get_*_dirs() sounds perfect this way for me, the foreach functions are fine too IMHO.
*** Bug 563992 has been marked as a duplicate of this bug. ***
If im not mistaken the proposed funktions have already been implemented in glib. So isn't this bug fixed?
Some of them are implemented: glib.USER_DIRECTORY_DESKTOP glib.USER_DIRECTORY_PICTURES glib.USER_DIRECTORY_DOCUMENTS glib.USER_DIRECTORY_PUBLIC_SHARE glib.USER_DIRECTORY_DOWNLOAD glib.USER_DIRECTORY_TEMPLATES glib.USER_DIRECTORY_MUSIC glib.USER_DIRECTORY_VIDEOS But it seems others are still missing like the USER_DATA_DIR And USER_CONFIG_DIR or USER_BASE_DIRECTORY. Would be nice to get these into glib as currently I would need to import another module to get them, like the unmaintained XDG module.
(In reply to comment #6) > Some of them are implemented: > glib.USER_DIRECTORY_DESKTOP glib.USER_DIRECTORY_PICTURES > glib.USER_DIRECTORY_DOCUMENTS glib.USER_DIRECTORY_PUBLIC_SHARE > glib.USER_DIRECTORY_DOWNLOAD glib.USER_DIRECTORY_TEMPLATES > glib.USER_DIRECTORY_MUSIC glib.USER_DIRECTORY_VIDEOS > > But it seems others are still missing like the USER_DATA_DIR g_get_user_data_dir(). > And > USER_CONFIG_DIR or g_get_user_config_dir() > USER_BASE_DIRECTORY. Not sure what that one is supposed to be. > Would be nice to get these into glib as currently I would need to import > another module to get them, like the unmaintained XDG module.
Ah, and they are available in python too. Sorry, my bad. Ok, closing this bug as fixed then :)