Pull requests concerning Windows support

[nshcat]

Hello,
I do realize that this crate is currently only compatible with the XDG specification, as stated in the readme. But for all of folders defined in the specification, one can find and query equivalent Windows environment variables, which can serve as a fallback on Windows systems. This is how the equivalent Haskell library goes about the problem of cross-platform support.

I'm going to do these changes on a fork of this repo anyways since I do need them for an application of mine, so would those patches be welcome here, or is Windows support a non-goal?

Cheers,
Katharina

[whitequark]

Non-goal. I think another crate could wrap xdg and something else to provide this functionality.

[piegamesde]

If you want to use OS-specific paths, the dirs-next/directories-next crates have you covered. If you want a funny mix-and-match system, that's what etcetera was built for (I think).

In principle however, the XDG specification is not limited to Linux. One can use the specified paths perfectly fine on Windows and Mac alike. Therefore I'd like to hijack this issue with the question: What's this current crate's Windows support? Will applications that depend on this crate build and work fine on non-Linux?

[whitequark]

In principle however, the XDG specification is not limited to Linux. One can use the specified paths perfectly fine on Windows and Mac alike.

Is this really true?

To quote one paragraph of the basedir spec:

If $XDG_DATA_DIRS is either not set or empty, a value equal to /usr/local/share/:/usr/share/ should be used.

Where is /usr/share/ on a Windows machine?

[piegamesde]

Um, yeah, it's definitely not "perfectly fine". Sorry for that.

But the user-local locations (data, cache, config, state) all have paths relative to $HOME, which does exist on Windows. To me, that's those I care about most anyway (because they're writable). I don't have any examples, but I think I've already seen some applications use them on Windows. This may make for a worse user experience, but that's still better than no support at all and also the paths can be configured from the user side if desired.

Regarding a potential implementation, one could feature guard methods and only expose those that work on Windows. Alternatively most methods could return an Option, which is what the dirs* crates do.

[whitequark]

I don't want to maintain the code that implements this behavior, or be responsible for supporting it.

[whitequark]

Closing since Windows support is currently a non-goal.

This may change in the future if the argument to do so is sufficiently convincing (e.g. if there is a consensus on using XDG on Windows that I can refer to when defining behavior of the crate.)

[dsisnero]

Fall back to windows defaults just like you fall back to linux defaults

XDG_DATA_HOME = %LOCALAPPDATA%
XDG_DATA_DIRS = %APPDATA%
XDG_CONFIG_HOME = %LOCALAPPDATA%
XDG_CONFIG_DIRS = %APPDATA%
XDG_CACHE_HOME = %TEMP%
XDG_RUNTIME_DIR = %TEMP%