#6036 POSIX: Use XDG dirs instead of HOME


We store information in ~/.scummvm. It would be better to use the locations defined in the XDG Base Directory Specification.



  • Eugene Sandulenko

    Well, ~/.* is the Right Thing(TM), Unix style, and 99.95% of programs use that. Gnome works mainly on *nix clones. I see no point of moving it anywhere.

    What are the advantages specific to our project? None of the things mentioned in the list you point to are applicable to ScummVM. E.g. it is safe to kill this file anytime, it is universal, backing it up = copy single file, data file paths are specified via GUI and are not enforced by the program, etc.

  • William Jon McCann

    Storing in $HOME is no longer the Right Thing(TM) on any unix style machine. This has nothing to do with GNOME. In fact this standard supports not only unix style systems but also mac and windows in most implementations. The GLib apis are particularly good in this respect.

    The advantages are for the user and admin, mostly. Not necessarily your project. Just being considerate to your users and a good citizen of the ecosystem I suppose. I don't think it really involves any cost. I can provide a patch myself soon I hope.

  • Eugene Sandulenko

    Does it mean that reading XDG_CONFIG_HOME environment variables is enough?

    Looking into glib sources, I see that if this variable is not set, it uses ~/.config, however the specifications mention /etc/xdg directory. So there is an inconsistency.

    Also this variable is not set neither on my Ubuntu 12.04 (with Unity), nor on Mac OS 10.7.4.

    Adding dependency on glib for the sake of retrieving this value looks like an overkill for me.

    So, any suggestions or hints?

  • William Jon McCann

    XDG_CONFIG_HOME and XDG_CONFIG_DIRS are different. The first is per-user and typically in the home directory. The second is systemy typically.

    The variable isn't normally set because the default is usually correct. However, a system admin or vendor can set it to whatever they wish. This is sometimes done when multiple operating systems need to be supported using a shared home directory.

    So, from a quick look it seems that dot files are used for a few things.

    log files -> syslog or XDG_CACHE_HOME/scummvm
    saved games -> XDG_DATA_HOME/scummvm/
    configuration -> XDG_CONFIG_HOME/scummvm

    One nice thing about glib (there are lots of nice things about glib) is that it takes care of windows support for you. But if you don't want to add a dependency on it you can just do the same things that it does. g_get_user_cache_dir() for example.

    Hope that helps.

  • Tarek Soliman

    Tarek Soliman - 2012-05-18

    I did some digging to find this out since some other games are putting their saves in ~/Documents/


    Basically shell scripts are supposed to check for and source ~/.config/user-dirs.dirs (they should look for $XDG_CONFIG_HOME and fall back to ~/.config)
    Then they'll get the environment variables.
    Stuff that runs at logs uses /etc/xdg to populate that file.

    (~/.config is the default for XDG_CONFIG_HOME)

    Implementing this shouldn't be too hard and ScummVM could probably fall back to the old behavior if anything goes wrong.

    Migration is a different story.

  • William Jon McCann

    Just curious, what games? Using Documents sounds wrong to me. I think using USER_DATA_HOME is better.

  • Tarek Soliman

    Tarek Soliman - 2012-05-18

    botanicula is the game but that's besides the point.
    The environment variables for xdg in debian sid are the following:


    There is no USER_DATA_HOME that I can see

  • William Jon McCann

    Ok, I'll try to follow up with that game and file a bug. Thanks for that info.

    From http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables
    "$XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used. "

  • Johannes Schickel

    I agree that adding glib as dependancy is really a bit much. Especially for using it on Windows, where it seemed a PITA to build it easily with MSVC. At least I had some troubles when I tired to do an x64 build. But that has been a while, so maybe it's better these days.

    As I understand it the base-dir specification was made to declutter $HOME and give some standard paths for different types of files used by programs on desktop machines. Then again the whole specification fails to point out any benefits, so maybe the intention here was something completly different... So I am not really sure I can say I like it too much. It would really be better when it would at least point to other documents which points out why using $HOME etc. is bad for example.

    It might make sense to adpot that standard never the less, looking at my $HOME/.local/share and $HOME/.config more and more programs seem to adopt it. The proposed places to put the config file, saved games seem fine to me. I am not sure whether I feel that "XDG_CACHE_HOME" sounds really a place to put a log, but I guess from the specification it seems the place which fits best.

    Anyway we need to make sure people with config files etc. in the old locations don't need to manually migrate to the new locations IMHO. That might need some small effort.

  • Eugene Sandulenko

    This bug is nice to get fixed before the release. Raising priority for keeping the track.

  • Eugene Sandulenko

    • priority: 5 --> 7
  • Johannes Schickel

    As it seems, there's currently nobody working on that.

  • Johannes Schickel

    • summary: use XDG dirs instead of HOME --> POSIX: Use XDG dirs instead of HOME
    • Group: --> *None
  • Johannes Schickel

    Appareantly nobody else bothered to work on this. I opened a pull request now which switches to this style, but still uses the old one if that has been around before: https://github.com/scummvm/scummvm/pull/656

  • Johannes Schickel

    • status: open --> closed-accepted
    • assigned_to: Johannes Schickel
  • Johannes Schickel

    Merged the PR so this is finally implemented.

    Users will need to migrate to new paths themselves for the time being. We still use the old locations if they are present.