iPhoto Library Manager 3.2.5 released
Posted on March 22, 2007 by Brian Webster
Filed Under Updates, iPhoto Library Manager | 7 Comments
Version 3.2.5 of iPhoto Library Manager was released today. The biggest change was the addition of a new option to help with keeping track of duplicates when copying albums or merging libraries.
There has been an option for a while to skip importing duplicate photos, so you don’t end up with multiple copies of the same photo. The downside to this was that if you copied an album over to another library, but some of those photos were already in that library, then only the photos that were newly imported (i.e. the non-duplicates) would get added to the album after the copy was complete.
In 3.2.5, there is a new setting in the preferences window that will tell iPLM to add the existing copy of any duplicate photo to albums that get copied over. So now, whenever you copy an album, all the photos from the original album will be added to the copied album, regardless of whether they were duplicates that already existed in the new library or non-duplicates that were just imported while doing the copy.
To see the full list of changes, check out the release notes. You can download the update here.
Setting a default iPhoto library for importing from a camera
Posted on March 16, 2007 by Brian Webster
Filed Under Tips & Tricks, iPhoto Library Manager | 3 Comments
This is a question that has come up several times from various customers. You may frequently switch back and forth between multiple iPhoto libraries, but whenever you import photos from your camera, you want them to only go into a particular library. However, when you plug in the camera, iPhoto opens up with whatever library you happened to be using last, so you have to quit iPhoto, go back and switch to the right library, then open up iPhoto again, which gets to be a pain in the butt after you’ve done it half a dozen times. So how you do get around this?
Image Capture
Lurking away in the Applications folder, often overlooked and unloved, is a little application called Image Capture. This is a general-purpose app for importing image data from various sources, such as cameras, scanners, or devices shared over the network. In the preferences window for Image Capture, there is a setting that allows you to choose what application to open up when you connect your camera.
Typically, this is set to iPhoto, and this is why iPhoto automatically pops up when you connect your camera. But we’re going to put something else there instead…
Applescript and iPhoto Library Manager
iPhoto Library Manager supports Applescript, so you can actually write a script that will open your preferred library for you automatically. We’re going to write such a script, save it as an application, and then tell Image Capture to open the script instead of iPhoto. (note: this script requires iPLM 3.1.1 or later to work correctly)
First, open up Script Editor (located in the Applescript folder inside the main Applications folder) and copy the following script into the editor window:
tell application “iPhoto Library Manager”
open library “Default Library”
end tell
This simple script tells iPhoto Library Manager to open the library named “Default Library” from your library list. iPLM will take care of all the logic of quitting and opening iPhoto as necessary, but of course you’ll want to type in the name of whatever library it is you want to import your camera photos into. You can test the script by clicking the “Run” button, at which point iPhoto should open up, displaying the library you specified.
Now we need to save this script and tell Image Capture to use it. Press command-S to save the script, making sure to save the script as an application from the File Format pop-up menu (see the screenshot below).
You can save it any place you want, as long as you remember where you put it. Your Documents folder might be a good place if you don’t have any better location for it.
Hooking it up
The final step is to go back to Image Capture, open the preferences window, and select “Other…” from the pop-up menu that lets you select the application to open when attaching a camera. Navigate to where you just saved the script, select it, and click “Open”.
Now, you should be all set to go. Connect your camera, and iPhoto should pop open with the library you specified. iPhoto will probably bug you, asking if you want to open iPhoto when you connect your camera, to which you can reply “No”. If you don’t want iPhoto Library Manager to stay open after it’s opened the library, just add another line reading “quit” (without the quotes) before the “end tell” line in the script.
Gathering data with PlistEdit Pro and Applescript
Posted on March 15, 2007 by Brian Webster
Filed Under Development, Tips & Tricks, PlistEdit Pro | Leave a Comment
All sorts of information is stored in property lists these days. It’s a simple but flexible format, used for simple stuff like application info and preferences to being the basis for some apps entire file formats. Browsing through property lists is fine and all, but there are some times when you need something with a little more oomph to sensibly look at the data you’re looking for. Some simple but well placed Applescript code in conjunction with PlistEdit Pro can yield some very useful results.
For example, in my various iPhoto related development, I’m often found in far too close contact with the AlbumData.xml file that iPhoto writes out, which is really just an XML property list. This file stores information on all the photos, albums, and rolls that exist in the iPhoto library. I recently found myself needing to look through the ID numbers of all the albums in a library, looking for duplicates. After about 30 seconds of twiddling down triangles and scrolling, I realized I needed a better way to get at this data.
Enter Applescript
OK, so you can write an Applescript that will iterate down into all those plists and compile the data for you. It would probably look something like this:
tell application “PlistEdit Pro”
set albumIDList to {}
repeat with albumPlist in plists of plist “List of Albums” of plist of document “AlbumData.xml”
set albumIDList to albumIDList & value of plist “AlbumId” of albumPlist
end repeat
return albumIDList
end tell
Well, that works OK, but with judicious use of Applescript’s test clauses, getting a list of the album IDs could be done in a single statement:
tell application “PlistEdit Pro”
get value of plist “AlbumId” of every plist of plist “List of Albums” of plist of document “AlbumData.xml”
end tell
OK, that looks like quite a bit to swallow at once, so let’s break that down, from right to left:
plist of document "AlbumData.xml": gets the root plist of the AlbumData.xml document, which is assumed to already be open in PlistEdit Pro. Result: a Dictionary plistplist "List of Albums" of...: gets the plist under the key “List of Albums” in the root plist. Result: an Array plistevery plist of...: gets every child of the “List of Albums” plist. Result: a list of Dictionary plists.plist "AlbumId" of...: this is where Applescript gets cool - without having to write any silly loops, this statement iterates through the list of child plists, extracts the “AlbumId” child plist from each one, and returns a list containing the result, no muss no fuss. Result: a list of Number plists.get value of...: again, loops through the list of “AlbumId” plists we just got and extracts the value property of each one, resulting in a simple list of the ID numbers themselves, which is exactly what we’re after. Result: a simple list of numbers
Not only is this version of the script somewhat simpler, but it’s also quite a bit more efficient, in that it doesn’t have to send individual commands to retrieve each ID and concatenate it onto our result list. This isn’t too bad in this example, but the difference can be quite significant in some applications (hint: try something similar with retrieving some message info from Mail and marvel at the speed difference)
Reading the results
Running this script in Script Editor should result in something like:
{2, 9.99001E+5, 9.99002E+5, 2580.0, 2578.0, 2579.0, 106.0, 107.0, 108.0, 357.0, 586.0, 587.0, 517.0, 427.0, 486.0, 411.0, 469.0, 538.0, 392.0, 442.0, 452.0, 458.0, 2265.0, 637.0, 655.0, 729.0, 2798.0, 2815.0, 3265.0, 3300.0}
But why look at it in that hard to read form, when you can just feed it right back to PlistEdit Pro for display?
tell application “PlistEdit Pro”
set albumIDList to value of plist “AlbumId” of every plist of plist “List of Albums” of plist of document “AlbumData.xml”
make new document at front of documents
set value of plist of front document to albumIDList
activate
end tell
Now you have a nicely displayed plist that you can sort, save, or do anything else you need to.
Applescript is commonly thought of as mainly being for automating repetitive tasks, but with a little practice, it can also become quite useful for one-shot items like this.
Welcome to Fat Cat Software
Posted on March 14, 2007 by Brian Webster
Filed Under News | 2 Comments
Well, after putting it off and putting it off (mostly because I like coding way more than website development), I finally got together a real website for my development work. I’d had my .Mac homepage and some individual product sites setup, but they were incredibly lame and there was no cohesive site for all my products, thus was born Fat Cat Software!
I’m sure I’ll have plenty of further tweaks for the site as I go along, but all the basic stuff is up and running now. I hope to actually do this blogging thing semi-regularly, with posts ranging from news and updates to various Mac tips and tricks to posts about Cocoa and other development topics.
RSS 2.0