Description

This applies to all platforms but Windows.

I was a bit unsure what the ggp platform even is, but it looked UNIX-
like enough so I moved it to XDG basedir too.

I didn’t attempt to do any migration since this is mostly cache, if this
is wanted please let me know, and I’ll update this PR.

I have also only tested on Linux, so more testing would be welcome.

See https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

GGP is Google Stadia, and should not be modified.

What is the actual added value in this change? Compliance with linux-specific specs is not useful as a goal in itself because linux specs tend to change with the seasons. There needs to be a notable benefit to the additional potential for bugs that something like this adds.

XDG base directory has been stable for almost 10 years, and is not about to change.

The main goal is to let users know what is cache (so it can be deleted without issue) and what is configuration (so it can be automatically backed up for instance), and to make it configurable.

This specification isn’t Linux-specific, it is cross-desktop and has seen minimal changes since its introduction in 2003, but wide adoption amongst software.

I have also reverted the ggp change, it now keeps using the old ~/.renderdoc directory for both configuration and cache.

To clarify I said it is linux specific speaking from RenderDoc's perspective - to me this is linux specific because it's not applicable to any other supported platform.

The linked specification seems more intended to cover interop and other standards, when different programs might need to share a config etc, not necessarily all software everywhere. I can understand that it would be a nice feature in principle to be able to store the cache separately even though it is pretty tiny. My concern is that this exposes potential for bugs by inviting variability in the system configuration especially on linux where systems vary wildly in unpredictable ways.

What about changing the file locations to be under .config/ and .cache/ but not using the environment variables? Then they are separated as you desire but there's not the brittleness of using environment vars in the file lookup.

I’m not sure which platforms you support exactly, but all UNIX-like should also benefit from it (all BSDs, macOS, Haiku, probably some other ones too), only Windows and Google aren’t considered.

The specification doesn’t mention sharing configuration, only where to store your own configuration, data and cache, in a way that is controlled by the user.

Which brings me to your third point, hardcoding the paths would prevent the user from being able to change the location of some of these directories. For instance, I’ve had a setup where the user’s home was on a tiny flash, it was very useful to be able to move the cache to a ramdisk and the data to an external SD card. It wouldn’t be possible to do that automatically for all software without proper support for XDG base directory.

Some software (especially proprietary games) do it like you mention, it’s always a pain to see these ~/.local/share and such being created again.

It’s also fine to use environment variables because you always revert to using the path relative to $HOME if they aren’t set, which they won’t be in most cases (and in the case they’re set, the user really wants to use it).

RenderDoc only supports linux out of those, none of those other platforms.

Is this an actual problem you have encountered in your own use of RenderDoc, or is it a theoretical fix you're applying?

It is an actual “problem” that there was a ~/.renderdoc/vkshaders.cache in my home after I started using RenderDoc, I would expect it to put it in the cache directory like most other programs on my system. The main reason for that is that if it ever started to grow, or to accumulate more cache, and I ran out of space, I would have to look into where this particular program put its cache, rather than nuke my ~/.cache entirely.

I've thought about it but I don't want to accept this change. The additional complexity and bug surface is not worth the value added by the feature. Moving to a .config or .cache directory would be fine though it seems artificial since RenderDoc's caches are tiny, but I don't want to add dependency on those environment variables.

Windows has the same feature by the way, and RenderDoc is using its API incorrectly as well (uses roaming appdata for local cache files).

Again, there is no dependency on any environment variable, only if the user has them set, they will be used instead of ~/.config and ~/.cache.

I’d really like you to reconsider your decision, all of your Linux users will benefit from it in a very obvious way.

I didn’t know about Windows also supporting that, should I update this PR to add support for it? https://crates.io/crates/directories#user-content-basedirs lists the relevant directories. I could also use the ones listed for macOS, but for these two operating systems I have no way to test.

@baldurk What exactly might be the issue with using the appropriate folders on the supported platforms?

Just like you'd use %LOCALAPPDATA%\app on Windows and ~/Library/Caches/app on macOS, you'd use $XDG_CACHE_HOME/app on Linux as per the freedesktop spec.

Putting caches and config in the platform-specific locations seem like the logical thing to do on all platforms, especially as it is such an easy task to just have a GetCacheFolder call. Same goes for config folder (%APPDATA%\app, ~/Library/Application Support/app or ~/Library/Preferences for plists, $XDG_CONFIG_HOME/app).

Also, note: ~/.config and ~/.cache are only common values, but just like a home folder may not necessarily be in C:\Users\ or /home, this should not be assumed, and the appropriate environment variables should always be consulted.

A good example where cache would not be ~/.cache would be a setup where the home folder is a network mount. Just like how Windows makes %LOCALAPPDATA% device local for performance but %APPDATA% domain global for persistence, $XDG_CACHE_HOME would then be a local machine folder outside the home folder, while $XDG_CONFIG_HOME would persist.