• The fix dead tracks, playlist/track copying, and merge functions now work with iTunes 9
• PowerTunes now understands the new layout of the iTunes media folder (formerly known as the iTunes music folder). The main place this affects things is to improve locating multiple tracks when using the Fix Dead Tracks command.
• PowerTunes now also recognizes the new default folder name of “iTunes Media” where applicable

So, if you have any older version of PowerTunes and have iTunes 9, I highly recommend using the “Check For Updates” menu item to update to the latest version.

• Copying tracks and playlists between libraries: you will not even be allowed to drag and drop tracks or playlists on a library to attempt to copy them
• Merging libraries: an error message will be displayed almost immediately upon starting a merge
• Fixing dead tracks: no items will be displayed in the dead tracks list, even if dead tracks are present in the library

An update for PowerTunes will be published soon that will address the issues listed above. Preliminary testing indicates that all other features of PowerTunes work normally with iTunes 9, so you can continue to switch between your libraries, create new libraries, find orphaned tracks, and so forth using the current version of PowerTunes (1.1). If you do experience any problems with PowerTunes 1.1 and iTunes 9.0, please use the “Contact Support” menu item in the Help menu, or e-mail support@fatcatsoftware.com

You can check the “Automatically check for updates” checkbox in the PowerTunes preferences window to be notified when the update is made available, and/or keep an eye on this blog for further postings.

In addition to the Info.plist file itself, you can also have one or more localized InfoPlist.strings files included in your application bundle. There are some strings in the Info.plist (e.g. CFBundleGetInfoString) which are displayed directly to the user, and thus need to be localized. Putting these keys in InfoPlist.strings instead of directly into Info.plist allows you to have localized versions of these strings.

However, Xcode’s Info.plist preprocessing only covers the actual Info.plist file, and not the various InfoPlist.strings files you may have included in your application bundle. This means that if you have a version number or some such that you want to keep up to date in one of these strings, you have to resort to replacing them manually, which is both error prone and a pain in the ass. I was able to solve this problem for my own project, and thought I’d share the details here in case it came in useful to anyone (and in case I forgot how to set it up in a future project and needed some help from my past self )

To get things working, I enlisted the help of a neat little tool called wincent-strings-util, courtesy of Wincent Colaiuta. It performs several tasks, but one of them is specifically geared towards doing this kind of substitution in a .strings file. In my setup, I simply include a copy of the tool in my project repository, so no installation is required and the build “just works” wherever you check out the project.

To get the substitution to be done when doing a build in Xcode, I defined a new build rule in my target to use a custom script to handle Info.plist files. To do this:

1. Choose “Edit Active Target” from the Project menu, click on the “Rules” tab, then click the “+” button down at the bottom of the window to add a new build rule.
2. From the “Process:” pop-up menu, select “Source files with names matching:” and then “*/InfoPlist.strings” in the field next to the pop-up. When I first tried this, I entered simply “InfoPlist.strings”, but that didn’t work because the match is against the whole path of the file, and not just the filename, so the * is necessary to match any file named “InfoPlist.strings”.
3. From the “using:” pop-up menu, select “Custom script:”, then enter the following script text:
   
   

   cd "${BUILT_PRODUCTS_DIR}" && ${SRCROOT}/DevFiles/wincent-strings-util --info "${INFOPLIST_PATH}" --strings ${INPUT_FILE_PATH} --output /tmp/${INPUT_FILE_NAME} --encode UTF-16LE

4. Where it says “With output files”, click the “+” button and enter “/tmp/${INPUT_FILE_NAME}” for the output filename

You can click here for a screenshot showing the completed build rule setup. A couple things to note:

• My major source of problems in getting this working was trying to deal with spaces in the various path names (my product name is “PlistEdit Pro”), and splicing together multiple build setting environment variables was not working well. That’s the main reason the script does a “cd” into the build directory, then works from there. That’s also the reason that I spit the output file into /tmp rather than somewhere inside the Xcode build folder, since trying to get it working there was more headache than it was worth.
• As I said, I keep a copy of wincent-strings-util inside my source repository. In my case, in lives in a subfolder named “DevFiles”. You should of course change this path in the script to the location where you choose to store tho wincent-strings-util executable
• The “With output files” section tells Xcode where to look for the result of the custom script. Xcode will then copy that result file into the appropriate location inside your built application bundle. If you do change where the –output argument of wincent-strings-util goes, make sure to change the output file to match.

Finally, to actually do a substitution, simply put a key from your Info.plist into the InfoPlist.strings file, enclosed in chevron brackets («»). For example, I have the following entry in my InfoPlist.strings file:

“CFBundleGetInfoString” = “PlistEdit Pro version «CFBundleShortVersionString», Copyright 2004-2009 Fat Cat Software.”;

This will replace the «CFBundleShortVersionString» placeholder with the value stored under CFBundleShortVersionString in the main Info.plist file. I have my Info.plist preprocessing already set up to include the version number of the build for CFBundleShortVersionString, so this will propagate that to the InfoPlist.strings files, and my version number will display correctly in the Get Info window for all localizations.

iPhoto Library Manager

Updated 9/16/09: A handful of users reported crashes when attempting to copy photos on Snow Leopard using iPhoto Library Manager 3.5.3. The cause of this bug has been found and fixed in iPhoto Library Manager 3.5.4.

PowerTunes

There are no known issues with Snow Leopard for the current version (1.1) of PowerTunes.

PlistEdit Pro

Only one issue was found in version 1.4.1 when running on Snow Leopard, but it was a fairly large one: plist files would not open in PlistEdit Pro when double clicking them from the Finder (the “Open” item in the File menu still worked properly). I just posted version 1.4.2 of PlistEdit Pro today, which fixes this problem, so if you encounter this issue, just use the “Check For Updates” menu item to update to 1.4.2.

I do my best to find any issues before an OS X update is released, but if you have any problems upon upgrading to Snow Leopard, please e-mail support@fatcatsoftware.com with a description of your problem, and we’ll try to get things figured out ASAP.

First, however a couple things to note about the data:

• Information is transmitted every time iPLM checks for an update. This check occurs when the user opens iPLM, but no more than once a day. This means that users that use the program more frequently will have a larger representation in the sampled data that users who only open iPLM on occasion. So, all the numbers you see here are based on number of checks, not necessarily the number of users. However, I feel that this approximation is good enough for sussing out general trends.
• Apparently, when I changed webhosts over from Dreamhost to Slicehost, I neglected to transfer the data that had been collected thus for over to the new server. D’oh! As a result, the data starts at the beginning of 2008, rather than several months beforehand.
• Due to a build configuration mixup with iPLM 3.5.2, profile information was not being sent correctly by that version. Since it was released in early June, that means the data for the last two months is pretty much worthless. So, the data presented will range from 01/2008 through 05/2009.

iPhoto adoption rates

The first thing I was curious about is how quickly users of iPLM update to a major new version of iPhoto when one is released by Apple. The data I have only covers one such release, iPhoto ‘09 (version 8.0), which was released in January 2009. Here is a graph of the usage rates of different versions of iPhoto by iPLM users:

As you can see, it only took about two months for iPhoto 8 users to surpass iPhoto 7 users. Granted, people who use iPLM are probably more advanced users and thus more likely to upgrade, but I still found this to be pretty impressive. And yes, there are still a few people out there using iPhoto 1 and 2.

OS X adoption rates

Unfortunately, since my data doesn’t start until Jan. 2008, it doesn’t cover the release of Leopard, which came out in Oct. 2007, so this isn’t the most exciting graph in the world, but you can at least get a sense of how many people are using Leopard these days:

iPLM updates

I don’t know how useful this really is, but I figured it might be interesting to see how quickly people updated to a new version of iPLM once it was released.

So it looks like it typically takes about two months for ~80% people to get updated to a new version after it gets released. However, keep in mind that this is data that’s only coming from people with auto-updating enabled, so there’s no telling how many users there are out there that have it switched off and are still running old versions. Overall the adoption rate seems pretty good though.

Registration rates

iPLM’s method of enticing people to buy a full license for the program is to limit access to a handful of “power-user” features such as copying albums and merging libraries. People can use iPLM for basic stuff for free without any time limit, but they need to buy a copy if they want to be able to copy their photos around easily.

It has also been speculated by many in the Mac developer community that the same users who are likely to upgrade their version of OS X are more likely to purchase third party software. Let’s see what the numbers are for iPLM:

It’s not huge, but there is a noticeable increase in the percentage of registered users as you move up the OS X food chain. My next thought was how registration rates compared to the version of iPhoto being used:

Now that’s more like it! It looks like users of newer versions of iPhoto are much more likely to have a registered copy of iPLM than those using older versions of iPhoto. This makes some sense intuitively, since the more involved you are in taking and organizing your photos, it seems you would be more likely to need iPLM and to update to the latest version of iPhoto, but it’s always nice to have data back up your assumptions.

For a limited time, if you purchase a copy of iPhoto Library Manager, you will receive a coupon code for 25% off a purchase of Duplicate Annihilator. You can download Duplicate Annihilator for a free trial to try it out, and if you like it, you can use the coupon code you receive on the receipt page after purchasing iPhoto Library Manager to receive your 25% discount.

You can use the “Check For Updates” menu item within the program to update to the new version, or you can download it here as well. This is a free update for anyone who’s already a registered user, so no additional purchase is necessary to update to the new version.

For those interested, here are the complete release notes for the new version:

iPhoto Library Manager 3.5 release notes

• Tagged faces are now transferred along with photos that are copied/merged between libraries in iPhoto ‘09
• Places data is now copied along with photos when performing a copy or a merge in iPhoto ‘09
• iPhoto Library Manager now creates its own log files and logs progress and error information as it copies photos (accessible from the Window menu)
• When using the “Import Photos” menu command, if the user selects an iPhoto library to import, we now perform a merge instead of treating the library like a plain folder
• Fixed a crash that could occur when copying photos on a PPC machine
• Fixed a bug where copying photos that were imported as aliases could result in an unneeded “modified” copy of the photo being created in the destination library
• A printable version of the help is now available at http://www.fatcatsoftware.com/iplm/Help/print/index.html
• Removed the preference setting for double clicking a library – double click now always opens the library in iPhoto, and a single click edits the library’s name
• When the user clicks the Cancel button, we now present a dialog to verify that they do in fact want to cancel the operation
• Removed the preference for relaunching iPhoto during a merge. This pref was for working around a bug in iPhoto 6, so we now just relaunch automatically when merging with iPhoto 6.
• Photos that were published to a MobileMe gallery are now always included in the main library during a merge, and not just in the gallery itself
• Fixed a problem where movies and original versions of photos would not be copied for some users
• Added a “selection” property to the Applescript dictionary so scripters can access the currently selected library

I’ve posted several new builds since the initial beta went out, and we’re now up to beta 12, which can be downloaded here. This fixes a couple persistent crashers from beta 5 onwards, along with several improvements in the photo copying process. If you’ve been running a previous beta and have encountered problems, I highly recommend downloading the new one.

There are still several minor items to be done before 3.5 can go final, but there are no more major changes to make, and currently no known issues. Of course, we’ll see if anything crops up this week as people have a chance to test things out, but I’m hopeful that the final release will be ready sometime next week. But, as always, nothing is written in stone, and I won’t be finalizing the release until I’m confident things have been sufficiently tested.

The main additions are, of course, the ability to copy Places and Faces data from one library to another when copying photos under iPhoto ‘09. This includes both copying individual albums/events and merging libraries. There are also several other changes and bug fixes included in the release (full release notes are at the bottom of this post).

This is pre-release software – I’ve tested things as thoroughly as possible, and there are no known bugs in the beta, but there is still the possibility of issues popping up, especially when dealing with library setups I haven’t been able to test myself. I strongly recommend backing up your iPhoto libraries before doing any major photo copying.

So, if you have iPhoto ‘09 and want to try out copying photos between your libraries while keeping your Places and Faces intact, you can download the public beta here. Note that I haven’t yet done my full suite of tests on earlier versions of iPhoto, and there isn’t really much in the way of new features for those earlier versions, so if you haven’t upgraded to iPhoto ‘09, there’s probably not much point in downloading the beta.

The system requirements are the same as 3.4.5, and you still need a registered copy in order to perform advanced features such as photo copying and merging. I will be posting updates as bugs get reported and things get fixed – you can use the “Check For Updates” menu item from within the program to check for and install any new updates. If any issues arise, please contact support@fatcatsoftware.com.

Update 4/3/09: Things have been progressing well, and iPLM 3.5 is getting close to completion. There are still a couple issues that need working out, but nothing major at the moment. I’ve just posted a new beta, 3.5b5, that is now available for download. Due to a mistake in 3.5b4, the “Check For Updates” menu item will not detect this new version if you have 3.5b4 currently installed, so you will have to download it manually instead from the link above.

Changes in iPhoto Library Manager 3.5 public beta

• When the user clicks the Cancel button, we now present a dialog to verify that they do in fact want to cancel the operation
• Removed the preference for relaunching iPhoto during a merge. This pref was for working around a bug in iPhoto 6, so we now just relaunch automatically when merging with iPhoto 6.
• Removed the preference setting for double clicking a library – double click now always opens the library in iPhoto, and a single click renames the library
• iPhoto Library Manager now creates its own log file and logs progress and error information as it copies photos (accessible from the Window menu)
• Photos that were published to a MobileMe gallery are now always included in the main library during a merge, and not just in the gallery itself
• Fixed a problem where movies and original versions of photos would not be copied for some users
• Tagged faces are now transferred along with photos that are copied/merged between libraries in iPhoto ‘09
• Places data is now copied along with photos when performing a copy or a merge in iPhoto ‘09
• Added a “selection” property to the Applescript dictionary so scripters can access the currently selected library

Just as a public service announcement, I thought I’d post about a conflict between iPhoto ‘09 and the Safari 4 beta that could cause some rather mysterious looking crashes, regardless of whether you use iPhoto Library Manager. The crash occurs when importing photos into iPhoto, but only under certain, somewhat odd conditions. The crash occurs when:

• You have both iPhoto ‘09 (version 8.0) and the Safari 4 beta installed on your machine
• You’re importing a batch of photos into iPhoto, at least one of which has embedded geotagging data
• This is the first import that you have done since launching iPhoto. If you first import a batch of photos with no geotags, then do a second import that does include geotags, it will not cause a crash

If you’ve been experiencing weird crashes when importing photos and have this affecting you, the easy solution is to uninstall Safari 4 and go back to using Safari 3. If you really don’t want to uninstall, you can also always remember to import a non geotagged photo before doing your geotagged photos (good luck with remembering that ).

My thanks in advance for everyone’s patience, I’d like to take my time and be thorough in testing to make sure the release is worth the wait.

• Places: Copying photos between libraries will not yet transfer any place tags that you’ve assigned to your photos using iPhoto ‘09. If the photos you imported were already geotagged before importing them into iPhoto, then that same data will be imported by iPhoto in the new library, but if you added the place data yourself using iPhoto, then that data will not be copied. This will be addressed in iPhoto Library Manager 3.5.
• Faces: Similarly, any faces you’ve tagged in iPhoto will also not be transferred when you copy/merge using iPLM. This will also be addressed in iPLM 3.5, though it’s not clear yet to what extent. From what I can tell, copying the actual face tags over to another library shouldn’t be too difficult. What I don’t know yet is whether iPhoto’s “learning” data can be transferred as well. For example, if you’ve tagged a whole bunch of faces in one library and iPhoto has learned how to recognize various people, I’m not sure if that training will be transferrable to another library, so any further faces added to a merged library wouldn’t benefit from the training in the original library. I’ll certainly be looking into doing this if possible, but it may prove to be too complicated to do.
• Facebook/Flickr: Right now, albums/photosets that have been created on Flickr or Facebook using iPhoto are basically ignored by iPLM. I’ll be looking into adding the ability to copy that information between libraries so that you don’t have to republish albums after copying them to another library.

You can download the 3.4.4 updates either by going to the iPLM home page or by opening iPLM on your machine and selecting the “Check For Updates” menu item. This is a free update for all users, so you can just replace your existing copy of iPLM with the new one with no additional purchase necessary.

Update: 2/12/09 An additional 3.4.5 update has now been released to address two issues introduced in 3.4.4. Updating as outlined above will now update you to version 3.4.5.

Now I’ll be starting work on iPLM 3.5, I can’t specify a hard timeline for when it will be done, but I’m hoping to be able to finish up by the end of February at the latest (and hopefully earlier).

• Viewing and switching between existing libraries works fine. iPhoto will prompt you to upgrade your library to the new version when you first open a particular library. Note that after you upgrade a library, you will no longer be able to open it in earlier versions of iPhoto.
• New libraries created using the current version of iPhoto Library Manager won’t work the first time you open them in iPhoto. For now, hold down the option key while opening iPhoto and use its interface to create a new library if you need to create one. You can then use the “Add Library” button in iPhoto Library Manager to add the library to iPLM’s library list, after which you can use the library normally. This will be fixed in the upcoming iPLM update.
• As expected, advanced functions such as copying albums between libraries and merging do not work and will produce an error message. Rebuilding a library will also not work, although the “Extract Photos” function should still work OK. Trying to use these features won’t result in any harm, they just won’t work. Again, these issues will be fixed in the upcoming iPLM update.
• iPod Folders appear to work with no problems with iPhoto ‘09

So, that’s what I have for now, I’ll be continuing to test things out and will post any updates on this page. I’ll then be starting work on updating iPLM to fix any of the issues that come up with iPhoto ‘09. That will be a free update for all users, so if you have purchased or plan on purchasing a copy of iPLM, you will be able to update for free when it is available.

Update 1/30/09: I’ve had a chance to work with iPhoto ‘09 for a couple days now, and here’s what I’m planning on doing. Two of the big new additions to iPhoto ‘09 are the new Faces and Places features. These features attach new types of metadata to your photos to identify people in the photos and where the photos were taken. It would obviously be very nice to be able to transfer from library to library when copying albums or performing merges. It looks like this is feasible, but it also looks like it will take a fair bit of work and time to accomplish.

So, what I think I’m going to do is to get out a quick 3.4.4 update for iPLM that gets things running under iPhoto ‘09 with the same capabilities as the current version. So, you’ll be able to copy albums, merge libraries, etc. but this first update will not handle any of the new Faces/Places data. The update will basically be to get people back up and running so they can use iPLM with iPhoto ‘09, fixing various issues such as the library creation bug mentioned above, etc. and should hopefully be available sometime next week.

Then, after that’s out, I’ll start in on getting Faces/Places integration working, and once that’s done, there will be a separate 3.5 update that will include that new, iPhoto ‘09 specific functionality. That will probably take a little longer, but it should be doable. If you have photo copying or merging you want to do but want to upgrade to iPhoto ‘09 right away, I would recommend doing any photo copying/merging you want before doing the iPhoto upgrade. That way, you can get your libraries straightened out, and then go ahead and assign faces/places in the upgraded library. If you assign faces/places and then do your copying/merging, you won’t be able to do so while retaining the face/place data until iPLM 3.5 comes out.