I also agree that this check is not really necessary. We already know the BundleID we are using, but it might have been put in place as Pd-extended had a different domain (and hence BundleID), so checking first would ensure the same plugin would work on multiple forks. We might want at least document this change and/or provide a better mechanism to check, although it seems macOS was the only platform to do this.
Following, I don't see a real reason why using the `defaults` command should be slow in and of itself (except for [1]).
This is perhaps a security mechanism where accessing the bundle's Info.plist directly is discouraged as it might be used by malware (my guess). Normally, you would query the defaults via the bundle ID or via the C/Obj-C/Swift APIs and *not* read Info.plist to get the bundle ID first. I don't see it as a Gatekeeper issue though, since the attributes were the same for the current stable release and this test3 release on my system:
% xattr /Applications/Pd-0.54-1.app
com.apple.macl
com.apple.provenance
com.apple.quarantine
% xattr ~/Desktop/Pd-0.55-0test3a.app
com.apple.macl
com.apple.provenance
com.apple.quarantine
[1] Saving Pd settings on macOS *used* to be slow (multiple seconds) as each setting was written individually using `defaults` from C. This was more an issue of making multiple system calls rather than an issue with `defaults`. I replaced that with using the Apple Foundation C API instead and it's very fast now. ;)
On Jun 2, 2024, at 12:00 PM, pd-list-request@lists.iem.at wrote: