Description
Currently, bsnes more-or-less supports the XDG BaseDir specification for storing configuration on Linux - it keeps some things in ~/.config/bsnes/ and some in ~/.local/share/bsnes/ and since #103 landed it even respects $XDG_CONFIG_HOME and $XDG_DATA_HOME.
However, bsnes' external-resource handling is really designed for the Windows model, where resources tend to be next to the executable, or in the user's home directory, and the distinction between config/data/cache and the user/system/vendor hierarchy don't really exist. I recall that bsnes and higan have at different times put everything in ~/.config or put everything in ~/.local/share for simplicity's sake, and I don't know if they're any more rigorous now.
Updating bsnes to properly follow the XDG BaseDir spec on Linux without regressing Windows or macOS may be difficult, but I'd like to get an idea for how difficult it would be:
- Investigate all the places where bsnes loads an external resource
- a good start would be finding all the things that call functions in
nall/path.hppand tracing their callers
- a good start would be finding all the things that call functions in
- figure out their access (read/write), and their type (config/data/cache)
- figure out a search algorithm for each combination of categories (read config, write config, read data, ...)
- check whether nall provides all the ingredients for discovering the paths required by the search algorithm (I think the raw parts are in
nall/path.hppand the path construction operations are innall/location.hppbut it would be good to check)
Once we have a good idea of where we are, and where we want to be, we can estimate how much work it would be to get from one to the other, and whether that investment is worth making.