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?

[timangus]

It's a thumbs up from me. My default action when trying to find a config file is now ls ~/.config; it feels increasingly anachronistic to have an application have its dot directory directly in your home. When we moved to %APPDATA% on Windows I remember it causing a bit of tension to begin with, perhaps we did it on the early side, but nevertheless it was the right move and indeed what everything does these days. (I do appreciate that was a slightly different situation though.) In terms of implementation details, I'm in broad agreement with the points raised, specifically:

• I don't feel particularly strongly over whether it's ~/.config/ioq3 or ~/.config/ioquake3 or ~/.config/q3a. These directories will be being created anew, so compatibility or interoperability in terms of the directory name shouldn't really be a concern. I will point out that using "ioq3" or similar is a departure from what we do in the analogous situation on Windows and macOS, where it's "Quake3", not "ioQuake3". So on balance I'd probably stick with ~/.config/q3a or favour ~/.config/quake3 for consistency's sake with the other platforms, but as I say I don't care that much.
• One question I have is whether ~/.q3a should still be read from when XDG directories exist, i.e. does it still form part of the composite file system? My gut feeling is no as it's another layer of complexity, but it seems like a potential source of confusion whichever option you take. e.g., if you don't read from it going forward and it contains existing pak files, the user is going to wonder where all their config/content has gone. If you do read from it going forward and it has existing pak files, the user is potentially going to wonder where this extra content is coming from when their XDG data directory is empty. I'm not sure there's a good technical solution here; it's a communication problem.
• We should definitely split the config and data. Not only is it odd to be writing screenshots and pak files into a directory structure whose top level is "config", it also directly ignores the standard and the whole point of the overarching change here is to adhere to the standard.

My only real concern, as I've already alluded to, is the upgrade path for existing users. There are a range of ways of dealing with this, of increasing complexity:

0. (Ignore ~/.q3a entirely, pretend it never existed. Don't tell the user anything.)
1. Same as 0, but rely solely on documentation and communication to inform users what changed (such as the text under the download links on the webpage).
2. If ~/.q3a is found on start up, show a message box informing the user of the change, and where their files will be found in future, what to do etc..
3. Same as 2, but offer to keep using the legacy path instead of the new paths. Not really a fan of this, fwiw.
4. Same as 2, but offer to automatically move their existing files in to the new paths. Would need a very careful implementation, as it would be making destructive changes.

In theory 2. is quite easy to implement so could be done at first, and if someone was keen 4. could be added later.

[ensiform]

2 cents wise, OpenJK project adopted XDG_DATA_HOME aka ~/.local/share/openjk many years ago instead of the root home ~/.DIR format and that seems like the best compromise to avoid splitting the filesystem up even further.

IMHO the separation with multiple XDG directories serves better with programs that are not games, there is not a lot of a benefit to adding this extra complexity into the filesystem.

I am back to a Windows user with new PC this year but was running for 5+ years on an arch-based distro previously and I can honestly say there was pretty much 0 games using the .config folder that I was actively playing in my experience. Also just quickly glanced at a few repos around the id-tech industry and found mostly using XDG_DATA_HOME or still HOME env, dhewm3 being one of the only ones I could find.

[timangus]

I'm not sure precedents really matter here. The point of having a standard is that everyone obeys the standard, so that everyone knows what to expect. Solely using ~/.local/share/whatever is directly disobeying the standard. If I want to find a config file for something, my first port of call is not /usr/share/program/something.conf, it's /etc/program.conf. Likewise, for a user config, I'm obviously going to look in ~/.config/program/ first.

So yes, it does make it a bit more complicated, but it's not like it's more complexity for complexity's sake, it's so that it's more intuitive to the user.

[timangus]

Added in #792.