Automator for AppleScripters

I’m not going to pretend I know AppleScript. I don’t. And I’m not just saying that to hide my lack of scripting skills. Really. I have none. But after starting to use Automator in Tiger, I quickly found that AppleScript is not only welcome in Automator, it can be a key part of it. And likewise, Automator can be a key part of AppleScripting.

Seems that there’s some nervousness on the Web that Automator is out to replace AppleScript. Nope. Let’s dispell that right now. Automator and AppleScript were designed to have a very symbiotic relationship.

I would have to assume that most who script have at least opened Automator and taken a peek inside. But just so we’re all on the same page, bear with me: Automator’s end product is very much like an AppleScript. Automator uses hunks of code or script packaged as kiddie building blocks called Actions. When you put these Actions on top of one another you create a stack called a Worklow. So Automator can be a way to package AppleScript. In fact, most of these Actions are just snippets of AppleScript. (Objective C can be used to create Actions as well.)

So, why just recreate AppleScript in a different box AppleScript can be much more specific than Automator’s Actions can. But Automator’s Actions can be much more convenient. Since Automator Actions are just packaged hunks of script, think of Automator as a way to speed up your scripting process by letting Actions do some of the work of common hunks of your script. Use Actions for the common parts of your script and then use the Run Applescript Action to get right to the meat of your script.

I don’t want it to sound like Automator requires AppleScript to run. It doesn’t. Over 200 Actions are built into Automator, with many more 3rd party Actions available at Apple and right here at MacScripter, most as freeware. Many new apps coming out contain built-in Actions. Like QuickTime 7. When you register it, the Automator Actions available jump from 4 to 16.

There’s a lot that Automator can do without a line of code. For instance, open Automator.

Click to see the Automator Window

On the left you’ll see the Application Library. These are the apps that Automator has Actions for. Right of that are the Actions themselves. The big blank space right of that is the Workflow. Click Finder in the Library. Double click Get Folder Contents. It will pop up in the Workflow. Check the Repeat For Each Subfolder box. Now click TextEdit in the Library. Double click the New TextEdit Document Action. Your Workflow will look like this:

Click for a screenshot of the workflow

Apple-S to save. Set the File Format to Application. Hit the Return key. That’s it. You now have a self-contained app that list the filepaths, folders and filenames of any folders dropped onto it and puts it into a TextEdit document.

You can easily do the same thing in AppleScript with a few lines of code. The point is that you can automate much of your scripting with Automator. If you’re familiar with XCode, you can create your own Actions from AppleScripts, further automating your scripting. As a matter of fact, when you install Apple’s developers kit, Actions pop up in Automator that automate the xCode building process and app packaging.

So isn’t the temptation just to write AppleScript code and turn it into Actions that you can use to build Workflows Not really. One serious Automator shortcoming is that Automator Actions must all be installed on the machine running them. So if you have third-party or custom Actions in your Workflows, they have to be installed onto other machines for your Workflows to be shared. Instead, if you pop a script (that does the same thing as an Action) into the Run AppleScript Action from the Automator Library, it becomes portable and goes with the Workflow where ever you send it.

If you double-click on the Run Applescript Action, you get:

Click for a screenshot of the Run AppleScript action

Yes, you guessed it, it’s a mini-scripteditor. Type or paste your code into the appropriate space here. This code can be as complex or as simple as you like. What this is great for is PseudoActions. For instance, surprisingly, there’s no Hide App Action. It’s easy enough to write a script that will hide the app Automator is working with. This requires that UI scripting is enabled:

--Hide App
	tell application "System Events"
		tell application "iTunes" to activate
		tell process "iTunes"
			keystroke "h" using command down
		end tell
	end tell

This comes in handy, since iTunes has a bad habit of popping up when its actions are called in a Workflow. I save these PseudoActions as Workflows and am able to call them up as easily as actions from Automator’s Library. Even if you have a long, complete AppleScript, you can paste it into a Run Applescript Action and run that single Action as a Workflow. What’s the advantage Automator allows you to save Workflows not only as self-contained apps (like Script Editor does) but you can also easily save them as plugins for Finder, Folder Actions, iCal Alarms, Image Capture, Print Workflow, or Script Menu. Automator is quite flexible.

There are many 3rd party Actions that are incredible in scope. RAWConvert is a good example. Jason Swain took Dave Coffin’s DCRaw command line tool that converts RAW camera images and converted it into an easy-to-use Automator Action. You can use it in a Workflow that will automatically fire when your camera is connected, convert the RAW files to jpegs and send them to iPhoto, create email size images of the files and mail them, zip the RAW files in an archive and burn them onto a CD. That’s all in the same Workflow. (At least in theory. Your mileage may vary.)

So, how well do these Automator Workflows, apps and plugins run There seem to be a few more quirks than with AppleScripts, but generally they’re efficient. Most likely if you’re on Tiger, you’ve already run a Workflow. Most of the options for burning to PDF in Print are Workflows.