GNOME Bugzilla – Bug 521066
default configuration files/dirs (XDG)
Last modified: 2019-03-20 11:37:30 UTC
In the old unix days applications stored all their configuration dirs and files in hidden directories under the users home dir. These worked well enough back then, since there weren't many applications storing stuff there. Nowadays however, there's typically about a hundred files and dirs in the users homedir. Dia still uses this approach, which is equivalent as to installing all programs into C:\ or /. The freedesktop organization took it into their hands to change this, and wrote a specification how to handle such data which can be found at: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html Luckily several projects have already started using this approach, unfortunately far to few however. XFCE for example was the first one to follow this standard as can be read at: http://blog.xfce.org/?p=63 and this is a good thing! I propose that dia follows the same guidelines, to remove the clutter from users homedirs by incorporating the basedir-spec as set by the freedesktop org, which would bring the config files into .config (the default for $XDG_CONFIG_HOME) .cache for caches etc. Other information:
There is support for this in GLib since version 2.6. It would also work - as it has to - on windoze. So for the patch the use of g_get_home_dir() needs to be adapted to g_get_user_data_dir(). For plug-ins lookup g_get_system_data_dirs() would need to be used, I think. Patches accepted.
change title to prepare finding duplicates
*** Bug 622207 has been marked as a duplicate of this bug. ***
I am willing to fix this. I just have a few questions: The configuration files should go to $XDG_CONFIG_HOME (default $HOME/.config) which we can get with g_get_user_config_dir(). The files in here are: * menurc * diagtkrc * pluginrc * defaults.dia * persistence The objects/plugins should go to $XDG_DATA_HOME (default $HOME/.local/share) which we can get with g_get_user_data_dir(). The files/folders in here are: * sheets * shapes * lines * xslt Is this correct or am I missing something? Also what should happen to the old existing configuration in the home directory? These cases i could think of: 1) The app checks both the old and the new position for a configuration. If both exist the configuration in the new position (xdg dirs) will be used. 2) The app checks if a configuration exists in the old place (the home directory) and then moves the directory to the new position. 3) Same as 2 but does not move the configuration but notifies the user that the position of the configuration has changed and advises the user to move the configuration. 4) The app ignores the configuration in the old position and only uses the new position.
As far as I know this is correct. Since users may want to keep their configuration data, I would do it as you proposed in 2) I wouldn't keep both, old and new config dir. I know that this is a problem for people downgrading their dia installation, but who will downgrade a major version?
Ok I implemented it as I proposed in 2) and it works. But I only tested it under Linux. The Dia FAQ 1.4.4 says, that under windows the HOME environment variable must be set and it was resolved in Version 0.88.1. Is the fix the platform specific code in the create_user_dirs function (app/app_procs.c) and is this the only reason for the platform specific code? In the implementation I removed the platform specific code, because now instead of g_get_home_dir, g_get_user_config_dir is used. In the same function, if the configuration directory can not be created, the app exits under *nix. There is a comment: /* HB: it this really a reason to exit the program on *nix ? */ So is there a reason to exit the program? Atm I keep it that way and will also exit if it fails to create the data directory.
Created attachment 312203 [details] [review] configuration files are now following the XDG specification configuration files are now in XDG_CONFIG_DIR data files are now in XDG_DATA_HOME existing files are moved to the new location
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/dia/issues/230.