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

Suggested Location for clap plugins on windows is ill fitted and outdated #389

Open
Yakehira opened this issue Jan 29, 2024 · 9 comments
Open

Comments

@Yakehira
Copy link

Yakehira commented Jan 29, 2024

For multiple users, Installing into Program Files requires UAC/Admin is honestly outdated for files like this and should not be done at all for plugins. For single users APPDATA is fine.

I would suggest that for Windows you switch to ProgramData\CLAP Plugins\Vendor\... as the recommended location for both Users, no need for APPDATA anymore, "clap" is too generic to use without a suffix, no admin access needed so another suggestion for Clap plugin providers themself would be to add a link to the startmenu for the CLAP Plugins folder as a generic entry point as ProgramData is hidden (so every plugin you install could overwrite it, but would not matter cause it's always the same folder), to make the clap folder itself more discoverable.

@abique
Copy link
Contributor

abique commented Jan 31, 2024

Hi,
How do you feel about making a PR?

@Yakehira
Copy link
Author

Im not really c coder, just a Windows user who is pretty annoyed that VSTs and co by default install into Program Files etc rather than having a very consistent 0 admin privilege folder, sadly Windows only really has the ProgramData (which is hidden) that can be accessed by multiple users and requires no admin privileges to write and read to (just the logged in user), but because it is hidden that's why Developers themself should create a generic Clap Plugin link to ProgramData\CLAP\ to improve UX (search for clap in startmenu and you get there), while Developers should put plugins into ProgramData\CLAP\VendorName\plugin.clap for consistency.

Though the suggested folder name CLAP Plugins is not be ideal due the space and isn't aligned with other platforms, so just naming it CLAP might be the proper move despite possibility of unknown interference. Other options could be CLAPlugins,CLAPPlugins (not good imo), CLAP_Plugins (a fix for the space)

@baconpaul
Copy link
Collaborator

Isn’t localappdata a user writable directory? That’s part of the spec today for clap searches

if a particular plugin doesn’t show that as an option in the installer you can raise an issue with that manufacturer but the spec right now has both a global and user area on all platforms

// CLAP plugins standard search path:

@Yakehira
Copy link
Author

Yakehira commented Feb 1, 2024

localappdata is user yes, but the current user so if you have more than one account on your PC you want the plugins accessible, you need to put them into a location that is outside \Users, thats why the suggestion to ProgramData is here because it's a location accessible by all users and requires no elevated privileges to access unlike Program Files.

@baconpaul
Copy link
Collaborator

so without endorsing this idea, your suggestion concretely would be, in that entry.h comment I linked above, for windows, add a third element which is

  //  - %PROGRAMDATA%\CLAP

yes?

@defiantnerd
Copy link
Contributor

I am not sure if this is really a good idea since it is not officially recommended though one could argue that it might not affect our target application:

https://learn.microsoft.com/en-us/windows-hardware/customize/desktop/unattend/microsoft-windows-shell-setup-folderlocations-programdata


Warning We don’t recommend using this setting, except perhaps in a test environment. The following are known issues

@Yakehira
Copy link
Author

Yakehira commented Feb 1, 2024

so without endorsing this idea, your suggestion concretely would be, in that entry.h comment I linked above, for windows, add a third element which is

  //  - %PROGRAMDATA%\CLAP

yes?

Yes, but the suggestion also focuses on making AppData and Program Files obsolete because moving to ProgramData for plugins no longer requires them as any user that is logged in can access ProgramData but with the drawback that this folder is a hidden folder but it's sadly the only folder Microsoft offers to install admin-less for all users, it's obviously still the developers own choice to put them wherever they want.

I am not sure if this is really a good idea since it is not officially recommended though one could argue that it might not affect our target application:

https://learn.microsoft.com/en-us/windows-hardware/customize/desktop/unattend/microsoft-windows-shell-setup-folderlocations-programdata

Warning We don’t recommend using this setting, except perhaps in a test environment. The following are known issues

The article you are referencing is for hardware implementors on how to author their images and not a guidance for app developers.

@baconpaul
Copy link
Collaborator

I can’t possibly imagine supporting my plugin users if I installed into a hidden directory so if this gets support I world strongly suggest it should only be additive to the search path.

@Yakehira
Copy link
Author

Yakehira commented Feb 2, 2024

I can’t possibly imagine supporting my plugin users if I installed into a hidden directory so if this gets support I world strongly suggest it should only be additive to the search path.

Yes that is the primary problem with ProgramData, it's hidden that's why a solution for app developers would be to create a generic link to it otherwise it wouldn't be a good location for plugins.

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

4 participants