Switch to using XDG base directories

[Legimet]

I would like to propose putting Enigma user config/data in directories specified by the XDG Base Directory Specification, since this has effectively become the standard on *nix systems to avoid cluttering the home directory (excluding MacOS, which has its own path).

I think we can use the following division:

• enigmarc.xml in XDG_CONFIG_HOME. I've also seen references in the source code to a Lua config file ~/.enigmarc. I'm not sure if this is still used (I don't have one on my system), but if so, it could go in the same place.
• thumbnails in XDG_CACHE_HOME
• everything else in XDG_DATA_HOME

Enigma could continue to support the old paths if they exist. Perhaps offer to migrate everything as was done for MacOS.

I would be willing to write a patch for this.

[raoulb]

I like the idea! Not sure how much work it would be.

[alochmann]

Hi!

Thank you for your proposition and analysis. Alas, it might be more work than you both assume, I think.

The .enigmarc file you found mentioned in the code? It (and .enigmarc2) are configuration files from very old versions, which we still read and interpret. We attach great importance to backwards compatibility: When our players update to a new version, all their settings and highscores should survive as much as possible. A simple renaming of the paths in the code would not suffice, we have to make sure that the old paths are read as well. And keep in mind that one of the options is to change the path to the options file. This is necessary for players who have Enigma installed on several systems and use a USB stick for their highscores. That is also why we currently use several different files for options: ~/.enigmarc.xml for system-dependend options, ~/.enigma/* for user-depended options. This way, the .enigma-directory can be shared on a USB, while system-specific options like screen resolution and path to .enigma can be found in .enigmarc.xml.

Also, we do embrace our users to actively use the .enigma-directory to put downloaded level files there. Might be more complicated if .enigma is buried deeper in the directory tree (or even somewhere like /usr/share).

So, I am fine with relocating .enigmarc.xml (if the old position is searched for as well), but I am hesitant about relocating .enigma.

Best regards
Andreas

[raoulb]

While I agree that backwards compatibility is important, sometimes a cut is necessary to move forward.

I think we should definitely adhere to modern platform-specific standards to where application configuration and data has to go. On Linux this would be XDG (and FHS for system level stuff).

At least this should be the default for new setups. We can still give the user the options to configure their systems in any way they like.

Following XDG we can (and should) split data according to its type (as mentioned by @Legimet). Configurations vs shareable data (user levels, scores, ...) vs caches (auto-generated thumbnails, ...) go to their respective directories instead of lumping it all together inside ~/.enigma/. I'd have to refresh on XDG a bit, but the essence is also summarized here:
https://en.wikipedia.org/wiki/Freedesktop.org#User_directories
(Afair the specification explicitly allows for some things to be shared across machines while other things must not be shared, so it might even handle the usb-stick use-case.)

As the paths would still be shown inside the application I don't think it is an issue if the directories are nested a bit deeper. (We could even open the file browser from within enigma with xdg. Most file browsers support some sort of bookmarks, ... So I don't see much trouble for players.)

About compatibility: we can still read files in legacy locations and warn the user or apply a migration (maybe triggered by a cli flag). But we should stop writing there. (BTW: I don't remember how old those legacy files are. Possibly pre-1.0? Which was released 18 years back!)

It is not clear to me how much effort code-wise this would be and hence if it is really worth the hassle. But I'd consider a well-made PR on this.

[alochmann]

The current .enigma-equivalent on Windows is buried deep as well, that is right, and people don't complain. I tend to concede. There are just two more points left I would like to raise:

1. Are the thumbnails really just cache? Creating them noticeably needs time and it might annoy users, if this "cache" is deleted on a regular basis by some foreign "clean-up" program.
2. Should we discuss this on the enigma-devel mailing list?

[raoulb]

About 1)
From the Enigma perspective, sure, they are a pure function of the startup level data.
For the file system: my understanding is, that the cache directory (in contrary to dedicated tmp dirs f.e.) is not cleaned up by automatic processes. So data should stay around until the user possibly cleans up by running some dedicated cleanup tooling. However, I do not know what all the flavors of modern desktops might or might not do.

About 2)
Yes, good idea. But maybe just point interested people to this discussion here instead of duplicating the topic? (Should all be readable at least w/o a Github account.)