My RSS Feed

The life of AppleScript

jlarson7 — 2009-10-03T13:52:51-07:00

MacWorld has an interesting article that questions whether AppleScript is alive and kickin or dead and Apple should move on and fill the void.

I personally don't think the language is dead. But it could be if Apple doesn't take it seriously. Things to improve: the language itself (why does it force the scripter to handle file paths?!), the script editor (either make XCode the script editor or make the current script editor a full featured editor and debugger), make implementing AppleScript easier for developers (no one will use it if it doesn't exist), and make AppleScript's recordability easier to implement (maybe power users can learn faster by watching than by reading, besides not everyone has the time to read, try, read some more, hang head, and repeat). Oh yeah, I almost forgot....more documentation (example scripts and snippets, and reference guides for each scriptable application and scripting addition).

Although its over a year old, Daniel Jalkut, the developer of MarsEdit, wrote an article noting that Apple appears to place more time and attention on improving JavaScript performance for WebKit than they do for the system wide scripting language, AppleScript. Although I agree with the sentiment, I disagree with the idea of making JavaScript the system wide scripting language. I think the major strength of AppleScript is its fairly easy to learn which means power users should be able to use it with minimal problems.

If anyone reading this agrees that AppleScript has major problems that don't seem to be getting the attention the language deserves, I encourage you to contact Apple or write up bugs and feature requests and let them know.

AppleScript's home

jlarson7 — 2009-08-23T14:00:34-07:00

Recently I tried to visit www.apple.com/applescript only to find I was redirected to a page devoted to describing the applications included in Mac OS X, specifically Automator.

Because that seems odd to me I thought perhaps Apple moved it and mistakenly directed visitors to the wrong location. Using Google, I discovered that what appears to be the entire content of www.apple.com/applescript has been moved to www.macosxautomation.com and I don't understand why. But I thought I would mention it to my visitors in case others were having trouble finding AppleScript's home as well.

Editing version names and other news

jlarson7 — 2009-05-05T22:56:59-07:00

Since I put this site up I have had a few people ask me for assistance with a script they are writing to automate Aperture. First, let me say I'm happy to hear users of Aperture are interested in automating Aperture as well as find this web site useful. And secondly, I am happy to help improve the content of this site using reader feedback.

A while ago I received a request for help from a reader/user that wanted to change an image version's Exif Image Date by 2 minutes. After thinking about the solution of his problem I realized that this script is far more useful than changing the Exif Image Date by 3 years. So I decided to remove my time shift script on the Metadata page that incremented the image date by 3 years with a script that will add 1 hour to the image date. Why not 2 minutes? Because I want to not only illustrate how to time shift but also provide a useful script to a wider audience. I assume more people will want to change their images' date in increments of an hour to deal with daylight savings time or a change in time zones than will want to change the minute or second. Either way, the modification required is very slight.

Another reader/user recently asked me a question concerning a script he was writing that will remove the file extension from the name of the image version. I thought it was strange that Aperture somehow placed the file extension in the image version name. After playing around with Batch Change, I realized if you change the image version name to the master filename, the images will be named something like: filename.cr2

Since some users of Aperture may see this as a problem and it can be created within the GUI of Aperture, I decided to a script that will get a selection of images and remove a file extension from the version name. You will need to modify the script so that it finds the particular file extension you want found. For those that may not realize where to change the script to handle your individual needs, I left a comment just below the line that should be modified. Enjoy.

Remove file extension from the version name.

tell application "Aperture"
set imgSel to (get selection)
end tell

if imgSel is {} then
error "Please select an image."
else

repeat with i from 1 to count of imgSel
set imgName to name of item i of imgSel
set newimgName to findAndReplace(".CR2", "", imgName)
--Replace .CR2 with the string you want to remove.

tell application "Aperture"
tell item i of imgSel
set name to newimgName
end tell
end tell
end repeat
end if

on findAndReplace(tofind, toreplace, TheString)
set ditd to text item delimiters
set text item delimiters to tofind
set textItems to text items of TheString
set text item delimiters to toreplace
if (class of TheString is string) then
set res to textItems as string
else -- if (class of TheString is Unicode text) then
set res to textItems as Unicode text
end if
set text item delimiters to ditd
return res
end findAndReplace

DISCLAIMER: I outright stole the find and replace function from Nigel Garvey which was posted a forum post on MacScripter. Since it was posted on a forum of a site devoted to learning AppleScript and this site does not collection money, I assumed I was ok to posted the function here.

Export command and selection property

jlarson7 — 2009-01-04T00:26:33-08:00

I recently received an email from a visitor wondering why his export script produced an error when attempting to export a single image out of Aperture.

From his email I realized I omitted a few valuable simple scripts from my collection of sample scripts that would have helped him answer several of his questions. Therefore I'm happy he emailed me as his feedback helps to improve this site.

I failed to have a simple selection script and a very simplistic export script. Both scripts have been added to the site. The selection script can be found at the bottom of the Basics page. And the new export script can be found at the top of the Exporting page.

One other thing I failed to mention about exporting images is the export command only handles lists of image versions. Attempting to export a single image will produce an error which was the root of the visitor's problem.

If your script generates an error but you feel everything should work, be sure to take a close look at the Applescript Dictionary for Aperture. The dictionary should provide all the necessary information to successfully use a command, class, or property. In this particular case the dictionary does state the export command exports a "List of image versions or projects to be exported." Overlooking something such as this is easy to do.

Aperture 2.1.1 released - new metadata field

jlarson7 — 2008-07-30T19:06:43-07:00

Apple released Aperture 2.1.1.

I decided to take a quick look at the Applescript dictionary and noticed one additional tag, “MasterProject” of the “other tag” class. Oddly this tag hasn’t been added to the GUI (I don’t see it in the metadata inspector nor in the Query HUDs).

In 2.1, there is a tag named “MasterLocation” which provides the full path of a particular image. However it does not give you the project object. Why would you want a reference to the containing project object?

Let’s start with a very simple structure in Aperture:

If I wanted to know the name of the project of the container of the image I currently have selected using such a simple structure, obtaining the project’s name and properties will be pretty easy. I could then use that name to refer to the project. As log as the structure is left flat, no two projects can be named the same and there won’t be a problem identifying a project based on its name.

Now let’s look at a more complex structure in Aperture:

As you can see, there are two projects that have the same name. Say I want to know the value of MasterLocation of a currently selected image found in “folder 1 > project 1”. After removing “folder 1 “ from the string, I now know the project’s name. Then I want to know the properties or something similar of that parent project.

tell application “Aperture”
get properties of project "project 1"
end tell

Which project will Applescript/Aperture return? I have no idea because both have the same name. What I want is the ID of the project which is unique and thus uniquely identifies the project and thus eliminates confusion.

Aperture 2.1.1 has a new field “MasterProject” which should help solve this problem because this field provides a reference to the project object. Now users can uniquely identify a project based on an image selection.

Photoshop Droplets as External Editor

jlarson7 — 2008-06-02T23:52:06-07:00

Although this tip has nothing to do with Applescript, it does involve Aperture and automating image processing using a 3rd party application.

One of the nice features of Photoshop is its batch processing of images and its ability to run recorded actions. The two combined together allow a user to apply the action against a directory of images or already opened images. Photoshop then allows a user to save a batch process along with an action using what Adobe calls “droplets”. The user can drop images or directories on the droplet and Photoshop processes those images using the instructions found in the recorded action.

Earlier today I created a droplet in Photoshop and saved it to my desktop. I then launched Aperture and made the droplet I just made as my external editor. The desire is to select a group of images in Aperture and have Photoshop process them using my droplet. I thought this would be really handy for preparing an image for printing or maybe I wanted a series of filters applied to the image. With Aperture 2.1, it seems as though the last image in the selection is the only one that Photoshop processes.

Although I wanted the entire selection in Aperture to be processed using the Photoshop droplet, this idea can still save a few mouse clicks. Without using this tip, you would have to instruct Aperture to open the selection in Photoshop. Once that is completed you then have to tell Photoshop to process the opened images using your action. Granted the time and effort savings isn’t terriby substantial although it could be if you were processing hundreds of images. One benefit of using a droplet as an external editor is images are handled one at a time by the droplet which is great if your images are large (imagine opening 20 200 MB TIFFs at once with 2 GB of RAM versus 1 image at a time using the same system configuration). If and when Apple addresses the problem and allows Aperture users to process multiple images using Photoshop droplets, this tip will save even more time and effort.

Adobting Aperture

jlarson7 — 2008-06-02T18:01:41-07:00

One thing that bothers me about Aperture, Microsoft’s Expression Media (formly iView Media Pro), and Adobe’s Lightroom is neither company has what I call “transition tools”. How do I go from whatever solution I’m using now to adobting your grand new image management application?

Because of XMP support, Expression Media and Lightroom probably are farther along than Aperture (yeah I know Aperture can read embedded XMP and can output XMP files but that output is limited and Aperture can’t read XMP sidecar files). However as far as I know neither Adobe nor Microsoft help current film users, users of a competitor’s product, users of even a custom made database, etc etc etc to switch to their solution. I’m surprised users go through with the move anyway, myself included.

Not all is lost when trying to move to Aperture, you just have to do some of the grunt work yourself. Say you want to move from Expression Media to Aperture or Lightroom to Aperture but you want to save all your metadata. Well first of all, your Lightroom adjustments will not work with Aperture because Adobe and Apple don’t use the same adjustments nor write the data to disk the same way. However your IPTC and custom metadata can careover to Aperture.

I’m not going to tell you exactly how to go about it. However, I will tell you the answer lies in the usage of Applescript, a tool named, exiftool, and the XMP sidecars. exiftool is the Swiss Army knife of metadata tools and among many other things it can read and write XMP files. So the idea is to read data from an XMP sidecar file for a particular image found in a directory, store it, then find that same image within your Aperture Library, you then write that data to the appropriate field within Aperture using Applescript. Of course this is probably not the only answer to the problem, perhaps others exists. This is just one I have discovered.

If you feel like going down this path, be sure to get a copy of the Exif v2.2.1 specification and the IPTC specification for IIM (Aperture 2.x does not yet support IPTC Core. Because of this you may end up losing some data, but you could keep it around by using custom fields. Not exactly ideal, but worth thinking about.). The specs may help you map out the fields between the applications as well as map the fields within the XMP file.

Aperture Assistant

jlarson7 — 2008-05-01T12:20:45-07:00

Earlier today I randomly decided to look at the activity of this web site by using Google's Analytics service. One thing I noticed was someone had visited this site due to a link from a domain named, aperture-assistant.com.

Well, it turns out aperture-assistant.com is the home of Aperture Assistant, a very visual based flow chart like application that basically runs applescripts for you but without having to write a line of code. Eh, imagine that. Programming turned visual. I'm sure many people will find this application far more useful than Automator (this is probably what Automator should be) and I'm also sure this application will be far more attractive to those users of Aperture that don't have time to learn Applescript or have a difficult time using it. I'm willing to bet that once I become decent at using Aperture Assistant I could beat a decent scripter in a race at writing up the same script.

After looking at the screen shots for Aperture Assistant, I suddenly realized that this is exactly how programming should be done. Why it has remained that way it has for so long is beyond me. This is very similar to the command line interface turned GUI. Once the GUI based operating systems came out, there were far more computer users. When I was in college I took a few programming classes. Each one forced students to create flow charts before even writing a single line of code. So currently a person has to convert what is in his/her head into a flow chart and then convert the chart into several lines of code. Then the person spends hours trying to figure what exactly went wrong during the conversion, assuming the flow chart was correct in the first place. But what if the person just created the flow chart in the computer and then the computer does the rest for you? I know I know, its a crazy idea having the computer working for you instead of you doing the work manually but hear me out. Imagine how many more programmers there would be and how quickly they could do their job. Oh wait....maybe that's why this kind of an application isn't too common.

My Applescript Wishes

jlarson7 — 2008-04-10T16:21:01-07:00

I'll admit I'm not great at writing scripts. With some time and patience I think I'm decent at getting the job done assuming the job is even possible with Applescript.

Let's take a stroll down Ranting Street...

1. I think using the language isn't exactly easy to use. But I think the language is easy to learn, but using it is a different matter. I have yet to come up with a good use for using just the language without actually automating an application. I suppose I could use it for a fancy calculator but I think there are other scripting languages and command line utilities and GUI apps already out there that would do a better job. Once you start automating an application, you have to learn how to automate that application. Then you move onto another application. The learning never stops. You can apply some things from what you learned with the 1st app, but the 2nd app could be drastically different and thus require more of your time and effort.

2. I think rant #1 would be addressed by addressing this rant. Where's Applescript's recordability in every Apple produced application? One of the features of Applescript is "recordability". Imagine being able to hit the Record button in the Script Editor and going through all the steps in the app you want to automate as you normally would. When your done you hit the Record button again to stop recording and your script is written for you. All of that without having to write a single line of code. You could record importing images from a directory, add some keywords after the import, apply some ratings, then export the project for whatever reason. Sounds pretty nice huh? So why isn't it available in Aperture? Because in order for an application to have recordability, the engineers developing the application have to implement recordability but unfortunately for us users they don't. I realize the Finder has some recordability but not much. I'm willing to bet there are more 3rd party applications with some recordability than all of Apple's software library.

Having this feature in Aperture would really make a workflow application a workflow application. It would save soooo much time and effort. Sure it wouldn't solve every problem out there. But it would surely save you tons of time, perhaps write the entire script for you, or at the very least give you a very good foundation to start with. I doubt this web site would even exist as well which is totally fine with me.

Also, why would Apple not implement it? Its their technology. Its an awesome time saver. And if you ask me, Automator is nice but its just a workaround for the lack of having good recordability. If recordability was in every application there would be no need for Automator.

3. Ever tried to write an application using Applescript Studio? The documentation isn't great as there are nothing specific to GUI controls and Applescript. The GUI control information is documented for the Cocoa programmer not the AS programmer. Well, I guess that's why they include so many examples. But that still doesn't answer many questions I have concerning what I can and can not do with a control and how I go about using a control, although the examples do help.

I'm sure I could come up with other gripes. But I think those are the real big ones for me. If you feel the same, I encourage you to contact Apple and let them know.

Scripting Resources

jlarson7 — 2008-04-10T16:12:56-07:00

I thought I would provide some scripting resources that may provide some useful information on using Applescript to automate. These resources should help writing scripts with Aperture as well as other applications.

Applescript Language Guide
This was finally updated last month. Always a great place to start. HTML and PDF available.

MacScripter
Samples, hints, tricks, etc etc.

Brett Gross Photography
Although not strictly Applescript, Brett does provide some useful Applescripts that automate Aperture in someway. Who knows maybe he has the very script you want already written.

Apple's Aperture / Applescript Page
This has some very nice demos that show off some very nice things you can do with Aperture and Applescript. My favorite is the InDesign integration. I would love to hear from users that actually use this or something similar in their work.

fullscreen property

jlarson7 — 2008-04-07T16:44:30-07:00

I just read through an article on another blog (Inside Aperture) concerning new Applescript stuff in 2.x. While I was reading it and looking over the dictionary I just realized something.

The application class in 2.1 has a new property: fullscreen.

The user can set and get the value of this property (it is a boolean property which means you set its value to true or false). The end result of setting this property is toggling the application fullscreen on or off. At this moment, I haven't come up with a good use for this but that doesn't mean one doesn't exist. Since Apple put it there, I'm sure its there for a good reason. I don't think its a good replacement/workaround for a slideshow because it takes some time to decode RAW files and thus the slideshow may get bogged down. But it may be useful for JPEGs.

tell application "Aperture"
set fullscreen to true
end tell

More new stuff for 2.1

jlarson7 — 2008-03-31T16:23:20-07:00

During the weekend I finally got around to upgrading to Aperture 2.1 as well as playing around with new Applescript support. I'm very surprised Apple has released 2.0.1 and 2.1 with additions to Aperture's Applescript but hey I'm certainly not complaining. Thanks Apple! I hope there is even more to come.

Oddly, Apple only mentions one aspect of the new additions to Aperture's Applescript in the release notes for 2.1. I'm not entirely sure why that is. Here's what Apple says is new as it pertains to 2.1 and Applescript: "Extended AppleScript support. The "Reveal" verb in the AppleScript dictionary has been extended to include containers such as projects and albums.". Well I see one more addition to the dictionary: Import/Export of projects.

Here's a few simple scripts to help get you started with the new features found in 2.1:

I noticed right away the reveal verb has been updated more than just revealing containers (projects, folders, and albums) after looking at the 2.1 dictionary. The 2.0.1 reveal entry is very basic and you could only reveal a single image version at a time. The 2.1 dictionary states you need to place whatever you want to reveal in a list which got me thinking....does that mean I can reveal more than one object at once? Well as it applies to images, the answer is YES! For some reason the same isn't true for the containers (I realize you can't select more than one container in the GUI, but then why make it a list?).

tell application "Aperture"
tell library 1
tell project 1
reveal {image version 1, image version 10, image version 2}
--reveal {project 1, project 2}
--doesn't work although the dictionary gives an impression of a multiple container selection

end tell
end tell
end tell

Revealing a container is similar to revealing an image version: reveal {project 1}.

Exporting a project:

tell application "Finder"
set export_dir to (choose folder with prompt "Choose a folder to export into") as alias
end tell

tell application "Aperture"

set x to name of every project
choose from list x with prompt "Select a project"
set ap_proj to item 1 of result
set ap_proj to project ap_proj

export {ap_proj} to export_dir with consolidating images

end tell

I got caught by a stupid syntax mistake when exploring exporting projects. If you accidently leave off "images" from that last line, the script will run and the editor will ignore "consolidating" which will be treated as a variable. There are times when the editor will catch cases where a variable is used but no value is assigned to it and produces the appropriate error message. For whatever reason, the editor doesn't catch this particular case and I was trying and trying to figure out why my referenced images where not being consolidated on export. BEWARE!

And importing a project:

tell application "Finder"
set import_dir to (choose file with prompt "Choose a project to import") as alias
end tell

tell application "Aperture"

set x to name of every project
choose from list x with prompt "Select a project"
set ap_proj to item 1 of result
set ap_proj to project ap_proj

import {import_dir} into folder "blue folder1"

end tell

What's really nice with the way they implemented the ability to import projects is you can import a project into a particular location within the hierarchy within Aperture. For example, I have a blue folder named "blue folder1". I want to import a project so that it resides within that folder without any manual assistance. With 2.1, that can now be accomplished.

New Applescript commands in 2.0.1

jlarson7 — 2008-03-03T17:35:22-08:00

Aperture 2.0.1 was released earlier today.

I noticed Apple has added three new commands to Aperture's Applescript dictionary: duplicate, move, and reveal.

reveal
Looks like this command will "reveal" an image version found in the library. Why would you ever want to use such a command? Check out an example on Apple's Applescript page and you'll know. By the way, this is gotta be my favorite feature in the entire application because of the power and time savings it creates. That page also has a pretty good video demo of the feature; check out the page just to watch the demo.

Here's a sample script to get you started:

tell application "Aperture"
tell library 1
tell project 1
set image_count to count of every image version

repeat with i from 1 to image_count
reveal image version i
delay 1

end repeat
end tell
end tell
end tell

I placed the delay command in there so the script doesn't fly through all the image versions. You can change the amount it delays (in seconds) to fit your needs. And of course you can also reveal an image version by name.

duplicate
Although this command is basically already provided to Applescript, it now does something in Aperture. What? It allows you to duplicate an image version from one container to another. Say you need a copy of a master in project 1 as well as in project 2. Looks like it works copying versions to albums as well. Here's how you do it:

tell application "Aperture"
tell library 1
duplicate image version 1 of project "project1" to project "project2"
end tell
end tell

move
Similar to the duplicate command, this command will allow you to move an image version to another project. I don't believe it works moving to an album. That seems right as you can't move versions to albums, you must copy them to albums.

tell application "Aperture"
tell library 1
move image version 1 of project "project1" to project "project2"
end tell
end tell

News...

jlarson7 — 2008-03-03T17:33:19-08:00

I'm not entirely sure how to post new information if and when Applescript support gets updated, bugs fixed, etc in Aperture 2.0 so I decided to do it using a blog. I figured a static web page probably isn't the way to go due to a lack of time stamps and other usability constraints. I hope this will be easier on you. Let me know if you think there is a better way.

With new commands, properties, and classes introduced (assuming Apple provides them), I will post information and examples here as well as update the other corresponding pages.