Place configs in $XDG_CONFIG_HOME

[mdosch]

Dear developers,

this is forwarded from openmohaa: openmoh/openmohaa#588

It would be nice if you could place the configs in $XDG_CONFIG_HOME according to the XDG Base Directory Specification:

There is a single base directory relative to which user-specific configuration files should be written. This directory is defined by the environment variable $XDG_CONFIG_HOME.

$XDG_CONFIG_HOME defines the base directory relative to which user-specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

$HOME is a lot cleaner if configs are in ~/.config/openmohaa compared to ~/.openmohaa.

[NuclearMonster]

Thanks for the issue.

I think this is a good idea for Linux, and my recollection is that id moved to using .config with Doom 3. This would be similar to Windows where we have a default of using %APPDATA% (as documented in the Player's Guide) but have a switch to revert to the old single-user behavior which is less supported these days by the OS.

However, I should say since ioquake3 (and id) has already supported a traditional user dot directory under Linux, there is less of a need to modify that behavior for Linux, in my opinion. I'd probably take a well-thought out PR that preferences the XDG standard for new installations under Linux (and I assume this is also the standard for desktop BSD, excepting macOS) but I'm happy to hear other thoughts on the subject.

[zturtleman]

XDG splits up config and data. I'm personally not excited for splitting it up as it seems like makes things more confusing. Doom 3 used ~/.doom3 but dhewm3 uses ~/.config/dhewm3 and ~/.local/share/dhewm3.

The majority of files should be in XDG data home; screenshots, downloaded pk3 files, etc. There is XDG data home support in ioquake3 for Flatpak.

Proof of concept PR (#703): Existing installs continue to use ~/.q3a but new installs use ~/.local/share/q3a.

Two questions;

1. Should the fs_homepath be ~/.local/share/ioquake3 instead of ~/.local/share/q3a?
2. Should XDG_CONFIG_HOME ~/.config/* support be added to write *.cfg files and CD/GUID keys there like dhewm3?

Honestly the answer to both of these is probably yes despite the code being more complex that way.

[NuclearMonster]

Thanks for coming up with a PR and your thoughts on this, zturtleman!

XDG splits up config and data. I'm personally not excited for splitting it up as it seems like makes things more confusing.

Completely agree, splitting up user files into two places makes little sense to me and I think will lead to more user and support headaches in the future. Still happy to hear feedback as to why that's a good idea. Maybe for managed installs via flatpaks and snaps there is some kind of benefit to having the two directories per application? Maybe the configuration directory would be less confusing for a user to browse if it is free of data files.

Proof of concept PR (#703): Existing installs continue to use ~/.q3a but new installs use ~/.local/share/q3a.

Two questions;

1. Should the fs_homepath be ~/.local/share/ioquake3 instead of ~/.local/share/q3a?

I think so, but it does potentially ruin interoperability a little bit which might stink. Would love to hear from the perspective of people making forks on this item. It's entirely possible we are already doing config file changes that are annoying, but at least we could avoid one. Do you have any thoughts from that perspective?

[smallmodel]

XDG splits up config and data

There is also XDG_STATE_HOME which would contain the logfile.

Splitting config and data could introduce a new headache, this could require a change in the FS code (like introducing a new fs_homeDataPath variable?), configuration files would have to be written in the fs_homeConfigPath and data files like custom pk3 (and saved games) would have to be written inside fs_homeDataPath. This would require FS_FOpenFileWrite to know where to store stuff like save games, logfiles, demos, pk3 being downloaded using auto-download... To avoid the headache, either XDG_CONFIG_HOME or XDG_DATA_HOME would have to be chosen.

Should the fs_homepath be ~/.local/share/ioquake3 instead of ~/.local/share/q3a?

Even if ioquake3 has interoperability in mind, it's still a different product that introduces some new features and configurations. I believe ~/.local/share/ioquake3 would be a better name, instead of q3a. Maybe there could be some configuration specific to ioquake3 that some users wouldn't want to be used in Quake 3 Arena?
in the filesystem, ioquake3 libraries are stored in an ioquake3 folder so it would be more consistent to also have configuration files stored in a directory named ioquake3 as in the product name. Maybe if the ioquake3 configuration file doesn't exist, it could use the existing q3a configuration file?