Use FreeDesktop $XDG_* paths when variables are set (fixes #2555)

[fpiesche]

This will make GZDoom preferentially use the FreeDesktop XDG directories on Linux for storing save games and configuration files if the relevant environment variables are set.

This will remove the need for e.g. Flatpak packages to have a permission exception to persist changes to the home directory; in a Flatpak the $XDG_DATA_HOME and $XDG_CONFIG_HOME variables are set by the runtime environment to paths specifically intended for storing user and configuration data respectively.

Rather than using ~/.config/gzdoom.ini, the ini file will now be saved to $XDG_CONFIG_HOME/gamename/gamename.ini if the variable is set, with a fallback to the old path if not.

Similarly, savegames will now store in $XDG_DATA_HOME/gamename/ by default with a fallback to, again, $HOME/gamename/

TODO:

• tidy up commit history
• fix this breaking Windows and mac builds
• figure out and implement migration from legacy to XDG paths

[fpiesche]

Apparently I also need to fix this up to not break macOS/Windows builds.

[the-phinet]

If following xdg, the fallback here should be "$HOME/.local/share/" GAMENAMELOWERCASE

or better, "$HOME/.local/share/games/" GAMENAMELOWERCASE (but the other would have to change, too)

[fpiesche]

I had set the fallback up to be the legacy paths, but will revise.

[the-phinet]

I assume you don't have actions enabled on your fork of gzdoom. You can enable them by going to the actions tab. That way you can see if a build will fail before opening a PR

---

I like what you're doing here a lot! Standards are a very good thing.

The compilation issue on other platforms is due to the prototype name change. Easiest fix would be to revert the name change.

[fpiesche]

Just want to check - do we agree that handling migration etc as per @exponentialmatrix's suggestion on the original issue is the ideal approach to take here?

• when writing files, follow XDG spec only and write to
  • $XDG_[DATA|CONFIG|CACHE]_HOME/$GAMENAMELOWERCASE if set
  • $HOME/.local/share/$GAMENAMELOWERCASE if not
• when reading files, check the following and use the first found:
  • $XDG_[DATA|CONFIG|CACHE]_HOME/$GAMENAMELOWERCASE (XDG)
  • $HOME/.local/share/$GAMENAMELOWERCASE (XDG fallback)
  • $HOME/.config/$GAMENAMELOWERCASE/ ("legacy"/current paths)

My only concern here is savegames - e.g. if a savegame exists in both the legacy and XDG paths with the same base filename, do we want to warn the user somehow, or just assume that XDG is the correct/more recent one?

I'm not sure how the menu for loading saves works; does it just take an array of full file paths and displays each item as one slot, or is each slot mapped to a specific base filename (ie. would e.g. $XDG_DATA_HOME/zdoom/saves/save00.zds and $HOME/.config/zdoom/save00.zds try to occupy the same slot?)

[the-phinet]

Just want to check - do we agree that handling migration etc as per @exponentialmatrix's suggestion on the original issue is the ideal approach to take here?

Yes, I agree with this approach. Though I want to clarify that when reading, the XDG fallback should only be used iff the respective XDG env vars are not set.

My only concern here is savegames - e.g. if a savegame exists in both the legacy and XDG paths with the same base filename, do we want to warn the user somehow, or just assume that XDG is the correct/more recent one?

Yes, XDG should superscede. I would toss a warn in the console like "Save file found at .config/gzdoom/saves/xxx.zds will not be read after version 5.something"

I'm not sure how the menu for loading saves works; does it just take an array of full file paths and displays each item as one slot, or is each slot mapped to a specific base filename (ie. would e.g. $XDG_DATA_HOME/zdoom/saves/save00.zds and $HOME/.config/zdoom/save00.zds try to occupy the same slot?)

I'm not 100% sure, but looks like each slot gets one filepath

https://github.com/ZDoom/gzdoom/blob/f892a750b20a7e6124d13a58be6940e6b8835acb/src/common/menu/savegamemanager.h#L10C1-L19C3