Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shader location on macOS #23

Open
knghtbrd opened this issue Dec 15, 2017 · 1 comment
Open

Shader location on macOS #23

knghtbrd opened this issue Dec 15, 2017 · 1 comment

Comments

@knghtbrd
Copy link

knghtbrd commented Dec 15, 2017

The README says you're putting shaders in /Library/Preferences/shaders on macOS, which I see in Cross::GetPlatformConfigDir is what you're doing. These really should be in a subdir under Application Support, say "/Library/Application Support/duganchen-dosbox" or something for a few reasons:

  1. Namespace collisions. This one should be obvious since you're dropping a subdir intended for very specific filenames.
  2. ~/Library/Preferences is the domain of Property List files. A few third party programs have dropped other things there over time such as ini files, but Apple defines that as serving the same purpose as DConf on Linux or a part of the Windows registry (HKEY_CURRENT_USER in particular). The correct place to put these things is under Application Support. ~/Library/Application Support serves as $XDG_DATA_HOME. The mapping isn't one-to-one since non-plist config data tends to get written there as well, which is why SDL 2.0.1+ return a subdirectory under $XDG_DATA_HOME for Linux or NSApplicationSupportDirectory for Mac.
  3. The contents of ~/Library are hidden from users by default. To be fair, for any program whose installation instructions begin with "git clone", you're good on this one. :) But if you're looking for a convenient installer at some point, SDL_GetBasePath will let you find your .app bundle. From that, shaders you supply might be located in there. shrug Apple likes search paths for such things for some reason.

Given the age of SDL 2.0.1, you're probably safe to use SDL_filesystem.h functions and not worry about their availability at this point.

@duganchen
Copy link
Owner

Heads up that if I don't get to this fast enough, I'll happily merge a pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants