News
AppleScript's home
Aug 23, 2009 @ 02:00 PM -
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.
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
May 05, 2009 @ 10:56 PM -
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.
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.
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.
Aperture 2.1.1 released - new metadata field
Jul 30, 2008 @ 07:06 PM -
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.
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.
Aperture Assistant
May 01, 2008 @ 12:20 PM -
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.
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.
fullscreen property
Apr 07, 2008 @ 04:44 PM -
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
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
Mar 31, 2008 @ 04:23 PM -
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.
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
Mar 03, 2008 @ 05:35 PM -
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
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...
Mar 03, 2008 @ 05:33 PM -
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.
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.