LINUX - Support XDG Base Directory Specification

Currently, all desmume files are stored in $XDG_CONFIG_HOME as a consequence of this patch. Although it is good that the user's home directory is not being littered with files, the XDG Base Directory Specification specifies that:

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

In essence, the standard specifies that configuration files should live separately to data files (at $XDG_CONFIG_HOME and $XDG_DATA_HOME respectively). Such data files include basically all non-config files - save files, cheats, save states, etc.

To allow seamless migration to the new standard locations, desmume should load data files preferentially from the new location, falling back to the legacy location where required. However, since the current method for determining a file location returns a directory independently of the specific file, the logic to fall back to the legacy location is hard to implement.

I propose that we add new path variables, on Linux only, to PathInfo; we duplicate the existing ones to accommodate both new and legacy locations. For example, pathToRoms now references the new location, and legacyPathToRoms references the traditional location.

We add an additional (optional) bool legacy argument to PathInfo::SwitchPath. This serves no purpose on Windows, but otherwise allows the program to specify whether the new or legacy location is required.

The logic to select between the two paths can be implemented in the code that calls PathInfo::getpath (or similar). When loading a file, the new location is preferred, falling back to the legacy location when required. When saving a file, the behaviour will be always to choose the new location, seamlessly migrating old users to the new system. For clarity, perhaps a one-time dismissable pop-up should inform users of the change (replies on forum threads such as this one may also help).

We can additionally take advantage of the separation of the categories of the paths to further tidy things up into subdirectories of $XDG_DATA_HOME/desmume, such as ./roms and ./battery.

I am willing to write a patch for the above (and maybe clean up some of the path code a little while I'm at it), but I have a few questions:

• Why, in mc.cpp, where the .dsv save file is accessed, is it relative to pathToBattery? In particular, what are the battery files supposed to be? Would it make more sense to have an additional category, pathToSaves instead, which puts its files in the directory $XDG_DATA_HOME/desmume/saves?

• Would you consider a refactor to allow the save file to be selected independently from the ROM itself? It certainly makes sense to have a default save location, but additional flexibility to have multiple concurrent saves on the go without manual file shuffling would be nice.

Some of the nitty-gritty of the current operation of the save system is explained, partially for future me's sake, below:

The various paths from which files are loaded are initially determined and set by function PathInfo::ReadPathSettings. This function invokes PathInfo::ReadKey for each key (type of saved file, e.g. BATTERYKEY) defined in path.h. On Windows, this reads from an INI file to determine the kind value of the key, falling back to the default path. On all other platforms, the behaviour is instead to always use the default path. Since the default path (pathToModule) is determined in function PathInfo::LoadModulePath to be within $XDG_CONFIG_HOME, all files are currently stored there.

Start by reading path.h and the implementations of PathInfo::ReadPathSettings, ReadKey, LoadModulePath, SwitchPath, and getpath. Trace the .dsv access in mc.cpp and identify how ROMs, cheats, save states, and other data currently select paths. Done means Linux prefers XDG data locations, falls back to legacy locations when loading, and writes new data to the new locations without breaking other platforms.