Thanks for looking into this, y'all.
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:
Message: 1 Date: Sun, 2 Jun 2024 10:40:16 +0200 From: IOhannes m zm?lnig <zmoelnig@iem.at mailto:zmoelnig@iem.at> To: pd-list@lists.iem.at mailto:pd-list@lists.iem.at Subject: Re: [PD] slow startup on macOS Message-ID: <76936eab-e81f-4b7c-a39d-37ff73c7d8dd@iem.at mailto:76936eab-e81f-4b7c-a39d-37ff73c7d8dd@iem.at> Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 6/2/24 09:34, Benjamin Wesch wrote:
On Sun, Jun 2, 2024 at 8:45?AM IOhannes m zm?lnig <zmoelnig@iem.at mailto:zmoelnig@iem.at> wrote:
[...] replace the dynamic reading of ::pd_guiprefs::domain
without really understanding the whole mechanism: isn't this already defined here then? https://github.com/pure-data/pure-data/blob/master/tcl/pd_guiprefs.tcl#L21
yes. (as i said: there should be some fallback mechanisms in place).
or probably just remove the lines 72-76
both options work for me.
thanks for confirming. i've created a PR [2331] for the fix. CI-builds should be available soon.
Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/