Am 2. Juni 2024 12:58:36 MESZ schrieb Dan Wilcox danomatika@gmail.com:
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,
There is no change.
I introduced querying the bundle id via defaults
, because I prefer a single source of truth, rather than hardcoding the same value on multiple places.
As discussed earlier this year (or was it last year?) I would like to eventually change the id of pd to info.puredata.pd, as we do not really have control over puredata.org.
The commit to dynamically query the bundle id was a preparation for sich a switch.
however, my progress on changing the id stalled otherwise.
although it seems macOS was the only platform to do this.
macOS is the only platform that has a bundle id...
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).
Either this, or because we are accessing our via it's absolute path. (So it looks like access to an arbitrary application - which is also what the popup warms about).
Maybe there's a more native way to access the bundle id within TclTk.
mfg.sfg.jfd IOhannes