Bundle Editor Release Notes

Resources Tab Extended Controls

The Resource Tab has been enhanced in Script Debugger 7 to make it easier to control the behavior and appearance of applets.

When you display the Resources Tab, either by clicking on the middle icon of the Show button in a window’s toolbar or choosing Resources Tab from the View menu, its appearance differs depending on the document type.

For simple scripts (.scpt files) and text (.applescript) files, the tab displays the file’s description. You can type in a description, or paste content — including images — from an editor such as TextEdit. Because the description is saved in a resource fork for these types of file, it can be lost under some circumstances, such as storage on volumes that do not support resource forks.

With applets and bundle (.scptd) scripts, the Resources Tab displays more information, especially in version 7. The various controls allow you to change the appearance of scripts, and in the case of applets, their behavior.

At the top of the tab is an area for the description. In this case the contents are stored inside the script bundle as a separate file (named description.rtfd), so it is more robust than in simple script or text files. It is also displayed in the splash screen of applets if you select Show Startup Screen, or you launch them while holding down the control key.

At the bottom is an area entitle Resources, which lists the contents of the bundle’s Resources folder. You can add files either by dragging them into the table from the Finder, by clicking in the + button at the bottom, or by using the area’s contextual menu. To remove items, you can use the delete key, the - button at the bottom, or the contextual menu. To rename a file, select it and type return, or use the contextual menu.

The contextual menu also includes commands for creating new files, including a folder for embedded Script Libraries, as well as to reveal files in the Finder, and to show a Quick Look preview.

Note that several of the files and folders are required, and deleting or renaming them will damage or destroy your script. Handle with care.

Info.plist Entries

Above the Resources area is a section where you change values in the applet or bundle’s Info.plist file, which in turn can alter the file’s appearance or behavior.

The first entry here is the the Bundle ID. Script Debugger tries to generate a suitable entry for you, based on the name of the document and the Bundle ID Prefix you have entered in the General section of Preferences. The Bundle ID needs to be unique — the Bundle ID Prefix should be based on your registered domain name if you have one, in reverse order — and only certain characters can be used (in particular, no spaces or underscores). Script Debugger will prevent you from entering illegal characters.

The next entry is the Copyright value. This also defaults to the value set for Copyright Notice in the General section of Preferences, and is used in the file’s Get Info window in the Finder. The default preferences entry includes placeholders for the year and the name of your organization (as entered in Contacts), as shown below.


The Version entry is next, usually taking either an integer value, or two or three numbers separated by stops — for example, 1.0. You can use other characters if you wish — the value is stored as a string. Like the copyright value, it appears in the file’s Get Info window in the Finder. It is also the value returned for an applet or .scptd library’s version.

The Build # is for your own use. If you check the Increment on save checkbox, the number will be incremented each time you save the file.

The Scripting Def. menu lists any scripting definition (.sdef) files found in the script bundle’s Resources folder. A scripting definition file is a special kind of XML file used to store an AppleScript terminology dictionary that can be used by the script, and is typically found in Script Libraries. When you attempt to open an applet or script bundle with a scripting definition file specified, Script Debugger will ask you whether you wish to open the script itself for editing, or the script’s dictionary for viewing.

The Applet Icon menu lists any icon (.icns) files found in the Resources folder. Icon files are a special kind of image file used for file icons, containing an image at multiple resolutions. By default, script applications containing open handlers contain an icon file name droplet.icns, otherwise they contain applet.icns. The standard Enhanced Applet icon is called AppIcon.icns.

To give an applet a custom icon, create a suitable .icns file not named applet, droplet or AppIcon, and drag it into the Resources area to add it to the applet’s bundle. You will then be able to choose it in the Applet Icon menu. When you add a custom icon, you do not need to remove the existing standard icon — when you edit a file they may be re-created anyway. (There are many simple applications that will produce .icns files from other graphic formats.)

The Code Signing menu lets you choose whether to sign the script after saving, and if so which signature to use. Script Debugger will list the available signatures, and assuming you have a valid Apple developer ID you will normally use one that begins with “Developer ID Application:”. This will enable your scripts to pass scrutiny by GateKeeper when you send them to other users. The Export Only option confines code signing to run-only versions created using the Export Run Only Script... command. Because code signing can take some time, especially when a script contains extra resources, you may prefer to sign versions you intend to distribute.

The Minimum OS entry lets you define the minimum version an applet will run under. This can be useful if your script requires particular features unavailable under some versions of macOS. If you are writing AppleScriptObjC code, the earlier of the value here and the value represented by any use AppleScript version... statment in the applet’s script will be used to filter terminology provided in code-completion: Script Debugger will try not to offer you AppleScriptObjC terms that require a later version than your specified minimum.

Enhanced Applets must have a Minimum OS of 10.10 or later.

ATS stands for App Transport Security, which is a way Apple restricts an application from making unsecure Web connections. By checking Allow arbitrary loads, you will turn off App Transport Security for the applet. You may want to do this if you are using AppleScriptObjC and loading non-https sites. App Transport Security supports finer control than a simple on or off, but that requires editing the Info.plist file directly. If you open a script that has been customized this way, the checkbox will appear in an indeterminate state, and you will only be able to turn App Transport Security fully on or off.

The Applet: Background only option configures an applet so that it does not appear in the Dock or menu bar. This can be useful for certain types of stay-open applets.

The Export: Include used libraries option is for users deploying scripts containing embed script libraries. When this option is checked, you can develop your scripts with script libraries stored in your ~/Libraries/Script Libraries folder. When you export a run-only deployment version, if this box is checked any used library scripts will be copied into the exported bundle.

Droplet Behavior

In this section you can modify how an applet containing an open handler behaves when files are dragged over its icon. You can also control how an Enhanced Applet with an open handler behaves.

There are two fields, which are empty by default. In this state droplets behave as always, allowing you to drag-and-drop any type of file or folder.

The Accept files with these extensions field is where you can enter extensions, siginifying that files with those extensions can be dropped on the application. You can enter multiple values; type a space or comma to start a new extension. Do not include the . character; Script Debugger will not let you enter it.

The Accept items conforming to these UTIs field is where you can enter one or more Uniform Type Identifiers, siginifying that files that conform to any of the entries can be dropped on the application.

Entering UTIs can be done in three ways. You can type them in directly, similarly to extensions, you can drag a file or files of the type you want over the field, or you can use the Add… popup menu above the field to enter some of the common system-declared UTIs (see screenshot of menu below). Apple also has a list of system-declared UTIs.

Saved applications will accept files that satisfy any of the entries in these fields. You can specifiy extensions only, UTIs only, or both.

See Also

Script Debugger 7 Release Notes

1 Like

Suppose I wanted a droplet to only accept folders or volumes. Is that doable?

Yes — check the Accept folders box and make sure the extension and UTI fields are empty.

Yes — enter a UTI of public.folder.

If you want just volumes and not folders, uncheck the checkbox and enter a UTI of public.volume.

The only real limitation is that you can’t say not to accept a type. So, for example, if you accept public.folder, there’s no way to exclude public.volume because it conforms to public.folder.

(Unless, of course, you make an Enhanced Applet, in which case you can do extra filtering in your own appletFileIsAcceptable() handler.)

1 Like

Just wanted to say this all sounds like great stuff. I’m just on vacation and it will be a while before I can test.

A few questions on Enhanced Applets…

When saved as an Enhanced Applet, if I don’t double-click to launch the script itself, and instead drag-and-drop a file directly on the application icon (as if it was not enhanced), the app appears to launch but does nothing. It merely remains open. Is this expected behavior?

If I launch an Enhanced Applet by double-clicking first, then drag a qualified file into the Enhanced Applet window, when the script displays a dialog as a sheet, it doesn’t not bring the window to the front. So there are scenarios where a partially obscured Enhanced Applet window does not show the dialog sheet itself. Expected?

So far, the Accept Folders checkbox and the ability to list acceptable extensions is working well.

This continues to look even better. Comments below should be taken lightly as I currently only have an iPhone while drinking beer in San Diego…

  • Since the default setting is to accept files and folders, under what scenario would I want to add public folders? Perhaps when I want to only accept certain file types AND folders? Does that mean when I add any file type that accept folders is automatically disabled?

And now, because of iPhone scrolling issues…and the beer…I will need to post other questions separately.

At least Shane will appreciate my efforts at work in the la-bore-ah-tory (Aussie pronunciation).

That, plus when you want to accept only folders.

Yes. A better way to look at it is that once you enter anything, what you enter is followed. Try to unremember that the Accept Folders checkbox ever existed :slight_smile:

:hear_no_evil: In your dreams.

I suppose you are right. My Australian accent sucks. I can still do Southern U.S. redneck, but that’s too depressing to even joke about these days.

However, I will share with you a unique excerpt from a best-selling work of fiction: Mr. Penumbra’s 24-Hour Bookstore by Robin Sloan. The main character extols the virtues of Ruby, so of course I’m sharing it with Matt. But I thought you might enjoy as well…

Programming is not at all the same. Normal written languages have different rhythms and idioms, right? Well, so do programming languages. The language called C is all harsh imperatives, almost raw computer speak. The language called Lisp is like one long, looping sentence, full of subclauses, so long in fact that you usually forget what it was even about in the first place. The language called Erlang is just like it sounds: eccentric and Scandinavian. I cannot program in any of these languages, because they’re all too hard.

But Ruby, my language of choice since my last job, was invented by a cheerful Japanese programmer, and it reads like friendly, accessible poetry. Billy Collins by way of Bill Gates.

But, of course, the point of a programming language is that you don’t just read it; you write it, too. You make it do things for you. And this, I think, is where Ruby shines.

Imagine that you’re cooking. But instead of following the recipe step-by-step and hoping for the best, you can actually take ingredients in and out of the pot whenever you want. You can add salt, taste it, shake your head, and pull the salt back out. You can take a perfectly crisp crust, isolate it, and then add whatever you want to the inside. It’s no longer just a linear process ending in success or (mostly, for me) frustrating failure. Instead, it’s a loop or a curlicue or a little scribble. It’s play.

Back to real work…and back on a Mac. I was curious what happened if not running the minimum macOS specified for an applet. I now see it puts the “not allowed” slash icon for the app.

Now…Build #. If specified, does that work with SD’s versioning feature (which I have not tried, but seem to remember something about) to increment back through versions?

Right — that’s the standard OS behavior.

The two are orthogonal.

You should be able to open any script you’ve saved with Script Debugger (and possibly Script Editor), and browse through previously saved versions. You can even run and debug previous versions in the browser.

It’s similar to version browsing in other apps like Script Editor and TextEdit, except it doesn’t include autosaved versions. It works with existing files because Script Debugger 6 has been saving the versioned files all along — it just never exposed the browsing side of things.

Because it’s an implementation of an OS-provided feature, it comes with some caveats — how the old versions are managed is a bit of a black box. It’s no substitute for a back-up system, but it’s useful for quick checks of what has changed, and particularly where you can old versions.

The other caveat is that running older versions can result in the display of other apps inside the browsing arrangement, which isn’t very pretty.