I tested macOS version of OXT Lite 1.0 (build uploaded yesterday)...
Testing on Big Sur.
First off, I get scary 'app damaged' message. I see you included a authentication cert and instructions on how a user can add that cert to their keychain. That seems like a bit much of an ask for end users to do just to run the app. When I first installed OXT Heavy (DPE) on a fresh install of macOS Sonoma, when I ran the app I was presented with a much different dialog that asked if I wanted to allow the software to run with a note something like 'Signed by developer Paul McClernan' and that the cert will expire in 2025 (which reflects the arbitrary date I used when I made my signing cert). Installer disk images can be signed and bundles can be signed. However, my main executable binary and the externals binaries, inside this app bundle, have all been stripped of code-signing (which I only did because I couldn't get mergRecord external to ask for microphone permissions, but now I've built an extension to replace that external). I'm still not sure which of there things makes the difference, or wether to leave the binaries unsigned or to use the custom made cert to sign them along with signing the .dmg and/or .app bundle (which is signs the bundle-folder itself, use the 'deep' option switch signs binaries in sub directories too). I don't think you should zip up the .app bundle like that, It's going to trigger the gatekeeper when it's unzipped, and a dmg disk image will likely already be compressed so there would be no point to zipping it too. That could be the problem.
Anyway I self signed it, adhoc sig using a drag drop utility called CodeSigner.app (useful) ...
Most serious issue is that if I click on the 'Window' menu or the 'Help' menu the engine sort-of half chrashes:
- OXTL1.0Crash.jpg (26.25 KiB) Viewed 877 times
Interestingly it offers the choice to continue running, but the Engine is either now locked up or unstable.
This seems to be initially triggered by there being nothing in the Window menu before any stack windows are open?
This is what the crash log says at the top:
Exception Name: NSInternalInconsistencyException
Description: Invalid parameter not satisfying: index >= 0
User Info: (null)
This doesn't happen on OXT Heavy, and it' only happened in the 'Windows' and 'Help' menus, so I'm guessing you've been tinkering around in the revMenuBar scripts
NEXT, my old favorite, Dark Mode!
At first I couldn't find darkMode which made me sad, but then I found that you moved it to a different tab.
However when I enable it, it does an emulated pseudo dark-mode, the window frames do not become dark.
- DarkModeNeedsMacLib.jpg (37.55 KiB) Viewed 877 times
As I've said, native 'darkMode' on macOS requires a bit more than just swapping fore/backGround colors.
I see that OXT macOS Native tools is included, but its native darkMode functionality is not being used.
If it's not done at the system API level (Apple's way) it's going to causes issues with other things like not having contrast making things unreadable or even appear to be invisible.
- DarkModeNeedsMacLib2.jpg (46.12 KiB) Viewed 877 times