I’m sending this out on the recommendation of Björn Eriksson of Einhugur.
I updated Xojo to 2025R1 and none of my programs would compile. After some investigation I discovered the Einhugur plugins had not been installed despite being in the Plugins folder. I contacted Björn for advice and sent him screenshots etc. He came back and told me I didn’t have the plugins installed, I had aliases to them and his plugins do not support aliases. I’ve been using aliases for years with never a problem. However, on his advice I replaced the aliases with the real plugins and the problem resolved.
Björn cannot understand why it ever worked and suggested I contact Xojo to see if you can shed any light on this.
I’m on an 2019 Intel Mac running Ventura 13.7.4.
Anyone got any ideas?
I don’t know if this works in Xojo 2025, but here’s the shell script I used for 2019 version:
#!/bin/bash
# UnzipXojoPluginsV2.command
# be sure to chmod +x this script file
# A script to uncompress plugin archives to have Xojo load them faster.
# see https://forum.xojo.com/57793-unzipped-plugins-still-possible/2019/1
# Changes from earlier versions:
# - Now properly handles Finder Aliases (the kind you get with command-option drag)
# this is useful if you like to keep your Plugins elsewhere
#
# - Is non-destructive - plugins (real or alias) are always moved to
# the Plugins_Backup/ folder
#
# - can be double-clicked: if you save this as a .command file (and chmod +x it)
# then you can simply double-click it in the finder to run it
# set the path to your Xojo app here:
ROOT="/Applications/Xojo 2019 Release 1.1/Plugins/"
cd "$ROOT"
# a backup folder where we move originals, so this script is non-destructive
backups="../Plugins_Backup"
mkdir -p "${backups}"
for f in *.xojo_plugin
do
if [[ ! -d "${f}" ]]
then
echo "Processing ${f}"
# if the xojo_plugin file is a Finder alias to a file elsewhere on disk
# handle it differently
fTruePath=`osascript <<EOD
set toPath to ""
tell application "Finder"
set toPath to (POSIX file "$ROOT/${f}") as alias
set theKind to kind of toPath
if theKind is "Alias" then
set toPath to ((original item of toPath) as alias)
return posix path of (toPath)
end if
end tell
return ""
EOD`
if [ "${fTruePath}" ]
then
echo "ALIAS: ${fTruePath}"
# for an alias, we have to move the original alias file to get it out of the way
mv "${f}" "${backups}/${f}"
mkdir "${f}" # create the _xojo_plugin folder
# unzip directly from the original file (not the alias) to here
yes | unzip -d "${f}" "${fTruePath}"
else
# this is not an alias file, handle it right here
echo "FILE: ${f}"
mv "${f}" "${backups}/${f}"
mkdir "${f}" # create the _xojo_plugin folder
# unzip directly from the file in the backup folder to here
yes | unzip -d "${f}" "${backups}/${f}"
fi
fi
echo ""
done
# Thanks to Jim Mckay for creating the original script.
I can confirm that unzipped plugins are still possible. My plugin management / updater tool Plugins Pro performs the unzipping process and I am using it with 2025r1
The Einhugur plugins arrive as .ecr files, which from memory are encrypted compressed files. When you buy a license you are given access to a de-cryptor and Xojo uses the output from that.
I’ve been using aliases for years, so why it should suddenly stop now is beyond me (and Björn).
What I’m suggesting is not officially recommended.
Maybe you already know this Tim, but the unzipped plugins can be made smaller if only targeting one or two platforms - by removing the unused target folders in the “Build Resources” folder.
In my case, I only build for macOS Desktop. I’ve been doing this for over a year without issue with all the latest Xojo versions. Works for both MBS & Einhugur.
I am not sure that benefits you in any way except saving disk space. Xojo only loads one target, so the other ones would not slow Xojo’s load. As in MacOS can only load macOS Dylib, and Windows can only load Windows DLL. So in the load procedure for plugins only the target you are on is loaded.
I knew about the unzipping of plugins from years ago on the forum, and how it does speed up the startup time a little. At first I was doing it manually, then I built a little utility to automate it (must have been before Tim’s Plugin Pro came along).
More recently I added the logic to strip out the non-macOS folders, just because I could.
I thought I discerned a slight improvement in startup time, but maybe it was just wishful thinking
Thank you for your feedback, Björn.
Note:
2024r4.2 with 33 unzipped Plugins takes ~8 seconds to show the “Choose a Project” dialog.
2025r1 with 22 unzipped Plugins takes ~6 seconds to show “Choose a Project”.
