FWIW, while the patient disentangling of property lists continues, my experience with AppleScript has always been that any script begins to get flaky (prone to random sudden fails) at around 1200 lines.
My guess is that some kind of memory resource gets too scarce at that point. AppleScript's stack is famously shallow, and that is unlikely to be the only hardwired memory constraint. Perhaps name-space allocations are also tight, for example ?
(AppleScript wasn't built to be used beyond a certain, rather limited, scale, and now that it is in its sunset – no longer actively developed by Apple – there isn't much prospect of relief for its lack of scaleability).
If scale beyond 1k lines is what you want, then AppleScript is probably not the right tool to reach for
After all that work, it's likely to start suddenly and inexplicably disappointing you.
I'm totally ignorant of BTT and am unlikely to dig through your code without first being tofd what you expect it to do as a result of a change to something somewhere. However, @Nige_S' post tells me a lot: the action as it appears in the KM Editor will never change.
You must understand that the action has "editor-time behaviour" and "macro run-time behaviour". But at no time does the actual appearance of the action's user interface (defined by the plist file) actually change.
The editor-time behaviour lets you change options, select from pop ups and type in text as defined by the plist. None of those changes - user interactions - cause any code in your script file to be executed. There is an exception: the action's title can include tokenised parameters and so at edit time the action's title can change but this is fairly limited.
The run-time behaviour takes the changes the user has made in the user interface at edit time and executes the script code with whatever parameters have been set at edit time by the user. At run time the action is not visible anyway, so changes to its appearance are irrelevant.
But, to repeat, the way the action looks in the editor cannot be changed. If you want it to look different then you have to define another, separate action.
@Nige_S has it right when he says the action's form is static.
When I started writing plugins I hoped that clicking a checkbox, say, in the editor would reveal somehow extra bits in the action's user interface. I soon had it confirmed that clicking the checkbox (and anything else for that matter) in the editor did not cause any code in the action to run - the checkbox state was available to the code when the macro is executed.
If my assumption that @Nige_S is on the right track is incorrect, then do please enlighten us with how you expect this action to behave in relation to those "changes" you mention.
When the PlugIn‘s appearance isn’t able to change in any ways like some build in Actions are able to (seen from a GUI perspective), then there will be no further checking and or testing until I’m done with my work.
My original plans of making only one PlugIn with changing options would result in a Mess of options and a PlugIn GUI that’s not even worth trying to describe.
It seems that I have to revert some of my work and put together a full Suite of several PlugIns.
I‘m sorry for having wasted anyone‘s time here. But I didn’t know that the kind of PlugIn I wanted to build seems currently absolutely impossible.
The Download links will be removed completely and unless Peter (@peternlewis) is telling me of any solution that I could use to get back to my original plans, I will work on a Suite of Actions.
Great idea! I opened the plist in situ and made a simple edit to one of the menu defaults and the Title text, saved it and then ran:
tell application id "com.stairways.keyboardmaestro.editor" to reload
The the appearance changed and defaults did change. Values already entered in unedited key/values pairs stayed the same.
The trouble is changes to a plugin's plist change all existing uses of the plugin. Changes to keys wipe out values. If the changed plist became invalid, on reload so do all the uses of it.
This is unlike what happens when you swap out the xml of an action via AppleScript.
The Editor will pick up the change and you'll see the appearance of the action change immediately. Other existing actions's xml don't change too. Whew!
