If you have moved to macOS 10.12 Sierra, you will probably have noticed that the AppleScript version is 2.5, unchanged from that in El Capitan. That doesn’t mean nothing has changed for scripters, though; there are at least a couple of things we have noticed.
First, there’s potentially good news for those who have suffered from their problem of their custom AppleScript syntax formatting suddenly reverting to default values. It turns out that the culprit was the choose application
dialog, which also appears if you mis-type an application name in a script (the dreaded “Where is…?” dialog). When this dialog was dismissed, it would try to save its position and size to use next time, but in doing so managed to stomp on the saved formatting information. Hopefully the problem is finally fixed for good.
You might also notice a subtle change in the choose application
dialog: as part of the fix, the dialog’s size and position are stored in the preferences of the application that summoned the dialog, which means if you move or resize it in one application, it will not affect the position and size it appears at in any others.
The second change concerns codesigning. In Sierra, the rules on what can be in a signed bundle have been tightened, and resource forks are no longer allowed. AppleScript has been saving information in resource forks forever, although that information has been unused for a long time. With Sierra, when you save a script, this resource fork information will no longer be saved.
So how will this affect scripters? If you don’t sign your code, it obviously doesn’t matter. And if you have applets written and codesigned under previous versions of the OS, they’ll still work fine. But it means you cannot codesign a script that was last saved in a version before Sierra; you have to save in Sierra to be able to sign in Sierra.
The only people likely to be affected by this are people who bundle other scripts within their scripts. They will not be able to sign the container script until all the embedded scripts have been resaved under Sierra. (You can also remove the resource forks using the xattr
command line tool.)
You will know you have struck this problem if you get an error message like this: <path to your script>: resource fork, Finder information, or similar detritus not allowed. Command /usr/bin/codesign failed with exit code 1
.
There are a couple of other changes that are not directly AppleScript related, but are of interest to scripters nonetheless.
Since auto-completion was introduced, there have been two system defined shortcuts: the Esc key and the F5 key. People have mostly used the Esc key, and indeed many people probably do not know that F5 works too. But in Sierra, the Esc key no longer triggers completion — only the F5 key.
This is obviously going to be significant for those who use code-completion in Script Debugger. Even if you are not planning to move to Sierra straight away, you might want to start thinking about migrating to the F5 key in preparation. If you are a heavy user of completion – and anyone using AppleScriptObjC is likely to be – the change can take a bit of getting used to.
The other big change in Sierra is the introduction of tabbed windows system-wide. Script Debugger has had tabbed windows for many years, and will continue to use its own implementation. So changes made in System Preferences will have no effect in Script Debugger; its tabs will be controlled by it own preference setting.
But a lot of applications that did not have tabbed windows will when running under 10.12, and how that effects scripting them might not be obvious. To understand what you can expect, it helps to understand how Sierra can magically add tabs to applications without changing their code.
The trick is that, as far as these applications are concerned, they are still opening separate windows for each document the same as before. The system then makes the windows all the same size and position, and only actually draws the frontmost one to the screen, along with a tab bar.
So when you script such an application, you too should treat the tabs as separate windows.
Working out how window tabs work in an application is just the sort of thing Script Debugger’s Dictionary Explorer view makes simple. Open a window or two in the application, open its dictionary, click on the Explrer tab, and see what documents and windows are listed. Open or close more documents, then click on the Reload button: the listing will be updated, with changed items in red.
(You should also think more in terms of visible windows. There was a time when the list of windows returned by an application was nearly always limited to those representing documents, but that is no longer always the case. And when you close a window, it may no longer be visible, but that does not mean it no longer exists or is omitted from the list. Again, Script Debugger’s Explorer will quickly show you exactly what is happening in a particular application.)
Lastly, Script Debugger has been using the AppleScript version number in use AppleScript
statements as a proxy for the minimum version of the OS that a script is intended to run under. This has been for the benefit of AppleScriptObjC users, and has enabled Script Debugger’s code-completion to avoid offering classes and methods that would be unavailable in the deployment target. Unfortunately the fact that the version in Sierra is unchanged has broken the link between AppleScript and system versions. This puts a bit more onus on scripters to check availability when targetting El Capitan.
If you are using Sierra, make sure you are using the latest version of Script Debugger – you should be using version 6.0.2 or later. You can see a list of the changes in in 6.0.2 here.
If we find any other changes, we will update this post. Let us know on our support forum if you spot anything.
Update: There is a further issue with codesigning. If the application or bundle you wish to sign contains other .scpt
files, perhaps as embedded Script Libraries, they will also prevent codesigning. An upcoming release of Script Debugger will strip the offending resource forks when signing, but in the meantime you can work around the issue either by using xattr
to remove the resource forks, or by saving the libraries as .scptd
files rather than .scpt
files.
1 thought on “Sierra de Nada?”
Comments are closed.