Disappearing iPhoto libraries on external drives

Posted on May 16, 2008 by Brian Webster
Filed Under iPhoto, Tips & Tricks, iPhoto Library Manager | Leave a Comment

I just came across this article on TidBITS explaining how to deal with stray “doppleganger” folders that get created in the /Volumes directory, where external hard drives and network drives are mounted by Mac OS X. I’ve seen this particular issue come up quite a number of times with people working with iPhoto, so I’m glad to see someone else writing on the topic. I encourage everyone to go read the article, since you never know when this will crop up on your machine, and it’s good to have this floating around in your head as a possible cause.

The way this typically affects people using iPhoto is when you’re trying to open a library that you store on an external hard drive. One day, for no apparent reason, you open up iPhoto and are greeted with a totally empty library. Where did all my photos go!? Aaaaagh!

You’ll be glad to know that your photos aren’t actually gone, they’re just in a slightly different place, so iPhoto can’t find them. iPhoto stores its library location by a plain path, so it will be pointing to the “doppleganger” folder, instead of following the library to its new path where the external drive is actually located.

iPhoto Library Manager itself uses aliases to track library locations, so when this happens, it will usually figure out to update itself to point to libraries’ new locations. If it doesn’t automatically update, all you have to do then is to re-add any libraries that are pointing to the wrong place to iPLM’s library list, either by using the “Add Library” button, or by just dragging each library into the list. You can then remove the old, stale references from the library list, and you should be all set. If you’re just using iPhoto’s option-key-on-startup trick to switch libraries, you can just do that and go find the real library on the external drive to get iPhoto pointed back to the correct location.

Miscellaneous Leopard development gotchas

Posted on November 1, 2007 by Brian Webster
Filed Under Cocoa, Programming, Development, Tips & Tricks | Leave a Comment

I’ve been using Xcode 3.0 under Leopard to do my development since Leopard came out last week, and thought I’d share a few changes that tripped me up.

Well, that’s what I’ve got for now, I may add more to the list later as I come across them. Hopefully this will help somebody out there (or maybe myself in a couple months when I forget and have to relearn this stuff over again).

Running FogBugz on Leopard

Posted on October 30, 2007 by Brian Webster
Filed Under Development, Tips & Tricks | 1 Comment

I use FogBugz as my main bug tracking and customer support system. It’s a neat application that runs on PHP and a web interface and allows me to both keep track of bugs/features in my development, as well as handle all tech support e-mail. It’s designed with a multi-user environment in mind, but works quite well for a one-man shop such as myself. The web interface is not as good as a true desktop interface could be, but it’s perfectly sufficient, and I’ve become quite dependent on FogBugz as part of my daily workflow.

Dependent enough that it was a rather rude (but not wholly unexpected) discovery to find that upgrading to Leopard pretty soundly hosed my FogBugz installation. Not that it went and deleted files or data or anything, but the setup was quite far from working normally.

The primary cause for this was that Leopard now ships with Apache 2.2, whereas Tiger came with Apache 1.3. All the various differences are well documented out there on the intertubes, but a lot of things, such as where configuration files are stored, changed between the two versions. For example, instead of httpd.conf being in /etc/httpd, it now resides in /etc/apache2.

I got that part figured out pretty quickly, but then when I went to start up the web server, I would get a message printed in the system console reading:

Oct 30 12:07:57 bw-mbp org.apache.httpd[11317]: httpd: Syntax error on line 484 of /private/etc/apache2/httpd.conf: Syntax error on line 8 of /private/etc/apache2/other/+entropy-php.conf: Cannot load /usr/local/php5/libphp5.so into server: dlopen(/usr/local/php5/libphp5.so, 10): no suitable image found. Did find:\n\t/usr/local/php5/libphp5.so: no matching architecture in universal wrapper

Hmmm, well, I do have a custom build of PHP5 (in /usr/local/php5, with additional extensions needed for FogBugz) and it seems to be finding that OK, but it’s complaining about architecture something-or-other. I’m still running on Intel, aren’t I?

[bw-mbp:~] bwebster% file /usr/local/php5/libphp5.so
/usr/local/php5/libphp5.so: Mach-O universal binary with 2 architectures
/usr/local/php5/libphp5.so (for architecture ppc): Mach-O bundle ppc
/usr/local/php5/libphp5.so (for architecture i386): Mach-O bundle i386

Yeah, that’s got an Intel build in there, that’s OK. What the heck is Apache’s problem?

[bw-mbp:~] bwebster% file /usr/sbin/httpd
/usr/sbin/httpd: Mach-O universal binary with 4 architectures
/usr/sbin/httpd (for architecture ppc7400): Mach-O executable ppc
/usr/sbin/httpd (for architecture ppc64): Mach-O 64-bit executable ppc64
/usr/sbin/httpd (for architecture i386): Mach-O executable i386
/usr/sbin/httpd (for architecture x86_64): Mach-O 64-bit executable x86_64

Oooh, I see 64-bit stuff in there, don’t I? I suppose that could be a problem if it’s trying to load a 32-bit library. Well, the packaged PHP that I installed from entropy.ch hasn’t been updated yet for Leopard, so I guess I’ll have to download and compile PHP myself so I can get in on the 64-bit goodness.

*insert footage of Brian downloading a bunch of stuff, typing ./configure and make, and seeing copious error messages fly across his terminal window*

Hmmm, OK, I think someone smarter than me is going to need to figure this stuff out. But I don’t have time for that, I want to get my FogBugz up and running so I don’t have to switch back to Tiger just to answer customer e-mail. If I could just force Apache to run as 32-bit instead of 64-bit, it should be able to load this PHP module just fine. Now let’s see, what would Dr. 90210 do…?

[bw-mbp:~] bwebster% man lipo

Yes, this is extremely hacktackular, and I’m sure there must be a better way to do this, but this is what I got.

[bw-mbp:~] bwebster% cd /usr/sbin

[bw-mbp:~] bwebster% sudo cp httpd httpd-fat

[bw-mbp:~] bwebster% sudo lipo httpd -thin i386 -output httpd

After making a backup of the httpd executable for safety purposes, the lipo commands sucks out all of the architectures included in the universal binary except the 32-bit Intel one (specified by “i386″). Apache can’t run as 64-bit if it doesn’t have a 64-bit binary!

After doing this, starting up the web server again worked just fine, and loaded the existing 32-bit PHP5 module. Once I got all my httpd.conf customizations moved over to the new location, that was pretty much all I needed to do. It also turns out that I probably would have run into this same problem for FogBugz specifically, since it loads its own fogutil.so PHP module which is also only available as 32-bit right now. I don’t know for sure, but I’m guessing people running on G5s, which also support 64-bit, would probably need the same trick, except replacing “ppc” for “i386″.

This is obviously a very poor long term solution, but if anyone needs to get FogBugz up and running on Leopard right away, this did the trick for me. Ultimately, getting FogBugz to work hack-free will require someone to get a 64-bit build of the PHP5 Apache module figured out, as well as Fog Creek providing a 64-bit build of their own Apache module. And of course what I’ve outlined here is totally unsupported by Fog Creek, so proceed at your own risk!

iPhoto 7 editing behavior

Posted on October 9, 2007 by Brian Webster
Filed Under iPhoto, Tips & Tricks, iPhoto Library Manager | 1 Comment

While fiddling around with the editing controls in iPhoto 7, I came across a small bit of new behavior that I thought may be interesting to some. If you use any of the sliders in the “Adjust” palette, iPhoto 7 will actually remember the positions of those sliders if you come back to that photo to edit it a second time.

Adjust.jpg

Picture after editing and reopening

This is in contrast to iPhoto 6, where opening this photo back up again would result in the “Temperature” slider being reset to 0. This is pretty cool overall, even if it prevents you from doing X-TREME 200% SHARPNESS adjustments by sliding the slider to 100% twice.

However, if you choose to edit your photo with an external editor, such as Photoshop or Preview, iPhoto will not remember these slider settings.

Adjust-1.jpg

Picture after editing in Preview

Also note that when copying photos with iPhoto Library Manager, transferring both the original and modified versions of the photo does the equivalent of editing in an external editor, so the slider settings won’t be transferred.

How to copy your keyword list from one iPhoto library to another

Posted on April 26, 2007 by Brian Webster
Filed Under Tips & Tricks, iPhoto Library Manager | Leave a Comment

One of the key features of iPhoto Library Manager is that it will copy a photo’s list of keywords when copying the photo from one library to another. However, this only helps for keywords that are actually assigned to one or more of your photos. What if you have a large list of keywords, but some of them aren’t actually assigned to any photos in your library? How can you take that keyword list and duplicate it in another library? Here’s one technique that utilizes this feature of iPhoto Library Manager:

  1. Open the library whose keyword list you want to copy and choose a photo in the library. We’ll call this our ‘dummy’ photo. You can even duplicate an existing photo to use as a temporary ‘dummy’ if you don’t want to be modifying any of the existing photos.
  2. Assign every keyword in the library to the dummy photo (or at least every keyword you want to bring over to the other library). Note that doing this through the keyword pane in the lower left is a big pain in the butt, since you have to draaaaag the photo on to each keyword over and over again. Try using the info window (command-i) which has simple checkboxes, much better for quickly assigning multiple keywords to a photo.
  3. Copy that photo over to the library you want to copy the keyword list to. iPhoto Library Manager will copy the photo over, then assign all the keywords in the list to the copied photo, effectively recreating the whole keyword list in the destination library.
    Copying a keyword list
  4. Now that the photo’s been copied and the keywords recreated, you can delete the dummy photo from the destination library. You can also return to the original library and remove all the keywords from the dummy photo, or just delete it if you made a temporary photo for this purpose.

Another similar technique, if you create new libraries fairly often and like to have a standard list of keywords in your libraries, is to create an empty library and use this technique to populate its keyword list, then just keep it around. Whenever you need a new library, instead of creating a blank one, just use the “Duplicate Library” command to duplicate this library, along with the whole keyword list. Now all your new libraries will start out with the same custom keyword list.

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.
Image Capture prefs

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).
Saving the Applescript

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:

  1. 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 plist
  2. plist "List of Albums" of...: gets the plist under the key “List of Albums” in the root plist. Result: an Array plist
  3. every plist of...: gets every child of the “List of Albums” plist. Result: a list of Dictionary plists.
  4. 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.
  5. 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.

Album IDs

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.

Feed