
Dunwich, Massachusetts<!-- iphoto_id: 4.294968014E+9 -->
The place: Route 9, Northampton, Massachusetts.
The time: Morning commute.
The car: late model Pontiac something or other, miniature dreamcatcher hanging from the rearview mirror.
The bumper stickers:
The Driver: The mullet made it hard to tell for sure, but I think it was actually a woman.
As much as people complain about stereotypes, I guess they gotta start somewhere.
Well what do you know... my sister has a weblog, and I never would have known about it if I hadn't seen it in my referrer logs.
I really must add a friends + family sidebar to the home page.
Yesterday I wrote of my surprise and annoyance at Apple for removing search by photo title in iPhoto 4. Yesterday evening it occurred to me that they didn't exactly remove it. In fact, iPhoto 4 now has a much more comprehensive search environment than previous versions.
The only catch is that to access this search feature, you have to first create a Smart Album and then use the "Where title contains" criteria.
The capability to search by just about every bit of information kept in the iPhoto database is there in the form of Smart Albums... but I still can't for the life of me understand why there's not the ability to do ad hoc searches; all they would need to add is a search field like the one at the top right of the iTunes interface, with a pulldown letting you specify that you want to search titles, comments, keywords, dates, et cetera.
This isn't even a feature that I depend on... but the absence of such an elemental feature of every other database I've ever used really gets under my skin.
I finally got my hands on iLife '04 - I haven't anticipated a piece of software as eagerly as I have GarageBand in as long as I can remember, and the upgrades to iPhoto were all welcome - but unbelievably, a useful feature has been removed from iPhoto in this upgrade.
When I jumped into iPhoto 4 (If it's iPhoto 4, why does the documentation refer to 'What's new in iPhoto 3?') and began playing with smart albums, one of the first things I wanted to do was look up a few images by title to which I haven't yet assigned keywords. Search by title was a feature that was previously somewhat clumsily implemented on the Keyword window. (In iPhoto 2, it's an unlabeled text box with a 'Search' button next to it underneath your list of keywords)
The feature is inexplicably gone in iPhoto 4... what was Apple thinking? The marginal 'Search by Title' functionality in iPhoto 2 was rough, but it was useful, dammit! Keywords are only useful as ways to designate loose groupings of photos; by season, or location, or the person or pet in the photo, et cetera... I don't want to create a keyword to describe every single photo in my library individually... otherwise I'd have an unsortable list of 500+ keywords. Describing individual photos is the logical place for titles to step in! Why in the world would this functionality be removed, even if it couldn't be improved upon from the previous version?
The only way to search photos now is by keyword, which renders the title and comment fields pretty much useless within iPhoto. I'm glad I've been dabbling with iPhoto's scriptable features lately, because it looks like I'm going to have to implement 'Search by title' myself. I'm not quite as pissed as I would be if that option weren't available to me, but I just find it mind-boggling that something as elemental as searching by photo title would have been removed in an upgrade.
I am not one of those twits who posts to usenet looking for a way to keep people from downloading images from his web site.
The fact of the matter is that stuff on the web, my photos included, are pretty much up for grabs if people really want them... it would be a waste of everybody's time were I to resort to all the stupid JavaScript tricks people have come up with to protect their precious, precious images.
That being said, the photos on this web site represent an enormous investment of my personal time over the years (not to mention AA batteries and gas money), so if you feel you must use one somewhere I would appreciate it if you give me proper credit and a link back to this site.
The XML-RPC calls work as described by the documentation and examples, but they make no mention of what to do if you need to send Base64 dataFor a while it looked like I might actually be able to consolidate my current Rube Goldberg iPhoto to Movable Type solution into a single AppleScript, thanks to OS X's AppleScript Support for Remote Procedure Calls.
The XML-RPC calls work as described by the documentation and examples, but they make no mention of what to do if you need to send Base64 data; in my own tests of the Movable Type metaWeblog.newMediaObject method, a base64 encoded string simply gets handled as a plain text string on the other side, and gets written directly to the file.
On a hunch I tried passing the raw file data as an AppleScript data variable, hoping against hope that the Apple Event handler would take care of the encoding on the fly, but as far as I can tell the raw data also gets passed along as a string, leading to a munged XML-RPC message.
And naturally, there's absolutely nothing out there on the web or usenet regarding this issue... I can't believe I'm the first person to try this, but perhaps those before me have given up in disgust before getting as far as writing about it.
I dropped the good folks at developer.apple.com a note regarding the documentation, politely suggesting that some clarification would be very helpful.. we'll see what happens.
In the meantime, I may as well make the XML-RPC call via PHP with a do shell script statement.
If anyone who comes across this has a solution, I would be most grateful if you could drop me a line with a quick code snippet.
Adapted from the 'Photo Summary' Apple's iPhoto Scripts Collection, here's some AppleScript that will set the comment of all currently selected photos at once; handy if you want to enter some common information about a bunch of photos, for example 'Family Reunion 2004 at Mayor's Income, Tennessee'
Be warned that any existing comment text will be clobbered by this script.
iPhoto Set Multiple Comments
set the image_count to the count of these_images
set comment_text to text returned of (display dialog "Enter a comment for the selected images:" buttons {"OK", "Cancel"} default answer return & return & return)
repeat with i from 1 to the image_count
set this_photo to item i of these_images
tell this_photo
set the comment to comment_text
end tell
end repeat
end tell
on error error_message number error_number
tell application "iPhoto"
activate
if the error_number is not -128 then
display dialog error_message buttons {"OK"} default button 1
end if
end tell
end try
on selected_images()
tell application "iPhoto"
try
-- get selection
set these_items to the selection
-- check for single album selected
if the class of item 1 of these_items is album then error
-- return the list of selected photos
return these_items
on error
return false
end try
end tell
end selected_images
Adapted from the 'Photo Summary' Apple's iPhoto Scripts Collection, here's some AppleScript that will set the title of each selected photo incrementally; so if you have three photos selected and you enter 'My Kickass Photo' as the base title, the photo titles will be set to 'My Kickass Photo (1)', 'My Kickass Photo (2)', and 'My Kickass Photo (3)'.
iPhoto Set Serial Titles
set the image_count to the count of these_images
set base_title to text returned of (display dialog "Base title for selected images:" buttons{"Ok", "Cancel"} default answer "")
repeat with i from 1 to the image_count
set this_photo to item i of these_images
tell this_photo
set the title to base_title & " (" & i & ")"
end tell
end repeat
end tell
on error error_message number error_number
tell application "iPhoto"
activate
if the error_number is not -128 then
display dialog error_message buttons {"OK"} default button 1
end if
end tell
end try
on selected_images()
tell application "iPhoto"
try
-- get selection
set these_items to the selection
-- check for single album selected
if the class of item 1 of these_items is album then error
-- return the list of selected photos
return these_items
on error
return false
end try
end tell
end selected_images
Route 119
Richmond, New Hampshire<!-- iPhoto Library ID: 569 -->
Route 10 Swanzey, New Hampshire
(Demolished in 2009)
Route 122
Orange, Massachusetts
<!-- iPhoto Library ID: 558 -->
Main Street at West River Street
Orange, Massachusetts
Thrown together in PHP.
Usage:
Encode | /path/to/base64 -e 'The quick brown fox' /path/to/base64 'The quick brown fox' |
Decode | /path/to/base64 -d VGhlIHF1aWNrIGJyb3duIGZveA== |
Help | /path/to/base64 -h |
Note that the script output is not succeeded by a newline, the reason being that I don't want to have to trim a newline every time I call this script from somewhere else.
#!/usr/bin/php -q <?php /* * Simple Base64 encode/decode shell utility written in PHP * (C) 2004 by Andy Chase (achase@greyledge.net) * http://sundown.greyledge.net * * Feel free to use and redistribute this code in any way you see fit, * provided this notice remains in place. */ $action = ''; $string = ''; switch($_SERVER['argv'][1]){ case '-e': $action = 'encode'; $string = $_SERVER['argv'][2]; break; case '-d': $action = 'decode'; $string = $_SERVER['argv'][2]; break; case '-h': $action = 'help'; break; case '': $action = 'help'; break; default: $action = 'encode'; $string = $_SERVER['argv'][1]; } switch($action){ case 'encode': echo base64_encode($string); break; case 'decode': echo base64_decode($string); break; case 'help': echo "Usage: base64 [-edh] [string]\n\t-e\tBase64-encode [string]\n\t-d\tBase64-decode [string]\n \t-h\tDisplay this message.\n"; } ?>
Another chapter in the ongoing saga of iPhoto to Movable Type via AppleScript... you would think somebody would have rolled and released a base64 encoding algorithm in AppleScript; I would love not to have to resort to another shell script call to encode images for transport via XML-RPC.
This has to be just about my biggest Usenet programming language newsgroup pet peeve of all time - the classic
"You don't want to do that. Never mind that you really do want to do that, I've decided that you don't."
See it in action on Google Groups.
In my ongoing attempt to perfect my iPhoto to Movable Type solution, I ran into the need to convert a Unix path (/tmp/foo.jpg) into an HFS style path (Mac HD:tmp:foo.jpg) that plays nicely with AppleScript's 'read' command.
Apparently this isn't all that common an issue, since file paths tend to be grabbed programmatically by AppleScript... but because I'm doing stuff with shell commands I'm working with Unix paths.
After much Googling, I found my answer in the first comment of a post on macosxhints.com.
In a nutshell, to convert a string representing a Unix file path into an HFS file path, do like so:
posix file "/path/to/my/file.txt"
This is probably not news to anybody who actually knows AppleScript, but I'm still stumbling my way along, grabbing other people's code and making educated guesses. The plain English style syntax is disconcerting.
It doesn't happen as often as one might expect, but every now and again I get bitten on the ass by the fact that most of my programming knowledge has been acquired on an as-I-go basis.
Today I spent far longer than necessary wondering why my lovely MySQL concatenation query kept returning NULL.
It wasn't until I did a Google search for MySQL CONCAT returns NULL that I was directed to the MySQL Manual, where I read that CONCAT always returns NULL if any of the referenced fields are NULL
In other words, I should have Read The Fine Manual to begin with.
News aggregators are very cool. First I read over at Wil Wheaton Dot Net that what was at first presumed to be a delay in communications due to an Australian thunderstorm appeared to be a much more grave problem, and then a few hours later (from the same WWDN post) I got the update that Spirit has responded and is commandable.
Well, that's pretty spectacular, and I can't imagine anyone being anything but excited at the news... but you know the people who can't imagine why we should have a space exploration program at all. They're actually going to be disappointed. I can hear the eye-rolling armchair rocketry now...
Oh, a billion dollars and it stops working because of a thunderstorm. Oh, that's great. Why don't we worry about our finding Osama bin Laden before we go send a billion dollar robot to look at a bunch of rocks?
These are the same people who, having completely dismissed the notion that maybe it might be a good idea for us as a species to have an exit plan, will then drive off to fill up their 5 Mpg Canyonero so they can go to Costco and buy 15 gross of disposable diapers to take back to their shiny new 15,000 foot McMansion built on what used to be pristine farmland. God Bless America.
The thing about programming things from scratch is that you get spoiled about flexibility.
Now that I'm approaching 300 entries in my Movable Type installation, I'm trying to think of new and sensible ways to organize my content, which now spans 5 years.
Naturally, my immediate instinct was to create an archive page summarizing entries by year and month... but perhaps Movable Type didn't really anticipate the need to manage so many entries, because there's not really any facility for organizing content by year and then month.
Enter the Archive Date Header Plugin from Kalsey Consulting Group, which does exactly what I need.
I've been lucky so far in that somebody else has already come up against the exact same needs that I have, and written a plugin to work around them. One of these days, though, I'm going to have to brush up on ::gulp:: Perl so I can write my own.
If you're doing any parsing on the 'image_date' field as grabbed by AppleScript, beware.I just noticed a strange thing about the iPhoto 2.0 date/time field - if you don't touch the date set by iPhoto on import, AppleScript will read the date in the format 'YYYY:MM:DD HH:MM:SS'.
If you go in and tweak the date manually, however, AppleScript reads the date in the format 'YYYY-MM-DD HH:MM:SS -XXXX' where XXXX is the GMT offset. (note the hyphens between Y/M/D, compared to the colons above.)
So, if you're doing any parsing on the 'image_date' field as grabbed by AppleScript, this will probably give you grief.