Alternatives to AppData (Windows) when storing files on other OS

Question

I'm working on a game project in Java and I need to store the config.ini file somewhere other than the executable jar location. I know people usually save them inside AppData on Windows, but I'd like to make my game completely portable with no OS restrictions at all. But to do so, I would need to know where to store such file.

I'd like to know where people usually store such files on other UNIX operational systems, mainly Ubuntu or Macintosh (OS X).

I'd also would appreciate if you could explain me a bit more about the directories regarding such OSs, since I do not own any of these systems. What I mean by that is, for instance, in Windows people usually drop their applications on their Desktops, while Mac users put them inside an Applications folder. In Mac's case, would creating a folder inside that Application directory be as bad as creating a folder on a Windows Desktop?

Also, on Ubuntu's case, where would the equivalent to AppData on Windows be located? And what about Mac's case? Would saving screenshots of the game or creating save games inside AppData or equivalents be a bad idea? I don't really want to use the usual Program Files directory.

And finally, a more code-wise issue. I know that in Java you can get Window's AppData location and concatenate such path like the below code:

Path FOO = Paths.get(System.getenv("AppData"), "BAR");

What about Mac and Ubuntu? And how would I be able to check whether the user is using Windows or Ubuntu?

---

Thank you very much,
-Renato

Answer 1

For most Unix-like operating systems, including Ubuntu and other Linux distributions, you should follow the XDG Base Directory specification, which describes where user preferences should be stored (namely, the value of the environment variable $XDG_CONFIG_HOME if it exists, falling back to ~/.config/). This directory is intended for configuration. Save games should go in $XDG_DATA_HOME or if not specified ~/.local/share, similarly.

OS X is also Unix-like, but uses its own paths. This is explained at Equivalents of XDG_CONFIG_HOME and XDG_DATA_HOME on Mac OS X?.