GNOME Bugzilla – Bug 522848
Gedit doesn't match FreeDesktop directories specs
Last modified: 2010-06-29 17:53:38 UTC
Please describe the problem: it seems that Gedit 2.22 (Ubuntu Hardy alpha 6) places its configuration files in ~/.gnome2/ which doesn't match FreeDesktop directories specs : The default for $XDG_CONFIG_HOME is $HOME/.config, the default for $XDG_DATA_HOME is $HOME/.local/share. So all applications should look for those environment variables and use those default values if the variables are not set. See http://www.freedesktop.org/wiki/Specifications/basedir-spec See also - http://ploum.frimouvy.org/?184-cleaning-user-preferences-keeping-user-data (main post and comment#8) - http://www.aigarius.com/blog/2007/01/10/fhs-extension-for-user-home-folders/ Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
And which is the FDO homedir-equivalent for /usr/lib and /usr/bin? We need those too, so currently it is easier to stick with our own directory layout within ~/.gnome2... Note that there are quite a few gnome apps that put their things into ~/.gnome2. Do you plan to report a bug against all those? If you did so for libgnome please add it in the "depends on" field below...
well... yes! Actually i'm filling bugs report against applications on my newly installed system (GNOME 2.22) which doesn't seem to match these specs. Totem already matches them, and also xcfa for instance. Parcellite and Specto also (in development branch) see comments from #19 at http://ploum.frimouvy.org/?184-cleaning-user-preferences-keeping-user-data#c44083 it may be like the port of applications to GFS : it may take some time i guess (and probably more since it is less "vital") I just want to warn developers about these specs, then they decide. These specs are for data and config files stored in the home participation if i understand things correctly /usr/lib and /usr/bin may not be involved i'm not sure and apologize for my english
(i wanted to write "home partition" and not "home participation) Sorry, i didn't understand "If you did so for libgnome please add it in the "depends on" field below..."
we need some /usr/lib equivalent to put the user plugins in.
sorru for not being enough competent to help you Maybe you could look at what Totem developers did since Totem also deals with plugins ?
use plugins etc go into ~/.local/share/gedit{/plugins} only configuration data goes into ~/.config/gedit caches into ~/.cache/gedit Note that g_lib actually supports this since 2.6. One of which is g_get_home_dir() -> g_get_user_data_dir()
*** Bug 601477 has been marked as a duplicate of this bug. ***
Created attachment 162816 [details] [review] Use XDG directories Renames all gedit_dirs_get_user_*_dir functions to gedit_dirs_get_legacy_user_*_dir and makes the functions static. Renames gedit_dirs_get_user_accels_file to gedit_dirs_get_legacy_user_accels_file and makes the function static. Adds new functions to replace those that were renamed. Adds the function gedit_dirs_get_user_data_dir which is used by the new gedit_dirs_get_user_plugins_dir function. Adds the new function gedit_dirs_migrate which is called in main(). The functions used to migrate a legacy directory/file is dumb in that if the new location already exist then the data is not migrated.
Review of attachment 162816 [details] [review]: I've added some comments: See that all of this migration thingie, is not needed in win32. So you should probably ifndef G_OS_WIN32 all the migration thingie. ::: gedit/gedit-dirs.c @@ +33,3 @@ #endif +#ifndef DEBUG why not using gedit-debug? @@ +336,3 @@ + } + } +#else not needed @@ +346,3 @@ + +static gchar * +gedit_dirs_get_legacy_user_cache_dir (void) this is not needed as it is not going to change @@ +408,3 @@ + } + } +#else this is not needed @@ +465,3 @@ + +static void +move_location (gchar *old_location, this should be const gchar *
Review of attachment 162816 [details] [review]: I know I am the one the always asked for automatic migration (and the approach you propose sounds good), but with if a clear migration strategy for gsettings does not exist, it seems a bit silly to go out of our way to migrate other stuff. In particular we should probably not migrate plugins since old plugins will not be loaded anyway. With regard to plugins I also do not particularly like to put them in data_dir, since they are not "data"... not sure where other apps put them. Some more comments inline, though figuring out what to do is the more important thing now. ::: gedit/gedit-dirs.c @@ +36,3 @@ +#define DEBUG(X) +#endif + use gedit debugging utilities @@ +348,3 @@ +gedit_dirs_get_legacy_user_cache_dir (void) +{ + const gchar *cache_dir; seems to me that the legacy cache dir is the same as the new one, so no need to migrate @@ +428,3 @@ +exists (const gchar *filename) +{ + return g_file_test (filename, G_FILE_TEST_EXISTS); I'd say to simply use g_file_test inline, the utility adds little convenience in this case @@ +434,3 @@ +isdir (const gchar *dir) +{ + return g_file_test (dir, G_FILE_TEST_EXISTS | G_FILE_TEST_IS_DIR); ditto @@ +440,3 @@ +isfile (const gchar *filename) +{ + return exists (filename) && !isdir (filename); no need to check if it exist, IS_DIR already implies it
Created attachment 162821 [details] [review] Use XDG directories v2 Updated based on reviews and comments on irc.
Created attachment 164878 [details] [review] Use XDG directories v3 Updated to apply after constifying the directory strings. This version does not so any migration as decided on irc.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
thank you :-)