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.

I don’t get special early releases of iPhoto or anything like that, so I’ll be working with it for the first time once I can pick up a copy from Apple. In the past, major iPhoto updates have required updating iPhoto Library manager to provide full compatibility for all its features, and I suspect things will be the same this time around. The basic functionality of iPLM (creating new libraries and switching back and forth between them) has never broken in any previous iPhoto update, so I’m pretty sure that stuff will be the same this time around. The more advanced features, such as copying albums between libraries and merging libraries together, however, require a bit more work to make sure they work properly. For iPhoto ‘07 and iPhoto ‘06, it has taken me about two weeks each time to issue an iPLM update for the new version of iPhoto, so it will hopefully take approximately the same amount of time this time around.

What I can tell you is that the update will be a free update for any existing users of iPhoto Library Manager, so if you buy a copy now, rest assured you will be able to use it with iPhoto ‘09 once the update is released. For those of you wondering whether to upgrade to iPhoto ‘09, you should still be able to switch between your libraries fine after updating, but you almost certainly won’t be able to do any photo copying or merging until the iPLM update is ready. If you really need to be able to use iPLM to do photo transfers, I would recommend holding off upgrading iPhoto until the update to iPhoto Library Manager is ready.

My thanks in advance for your patience, I will be posting further updates on how things are going as I learn more about what needs to be done for the update.

One thing that is not in the update, which a few people have asked about, is support for managing iPhone applications using PowerTunes. Unfortunately, this is not a simple matter, because as of iTunes 8.0.2, Apple does not provide any mechanism for accessing the list of iPhone applications that are in a given iTunes library. I’ve even filed enhancement requests for this, but suffice it to say, I’m not confident that Apple will be adding this functionality anytime in the near future. So for now, managing iPhone applications will have to be done manually, I’m afraid. I will be looking into other ways of assisting with this in upcoming releases though. And feel free to (politely) bug Apple for this functionality for me if you feel like it.

The trick is to create a disk image that, when mounted, Image Capture believes to be a digital memory card, and treats as a digital camera, so it shows up in iPhoto, Image Capture.app, and so forth. There appear to be a bunch of different ways to do this, but here’s the method I used that worked for me:

1. Open Disk Utility and click the “New Image” button in the toolbar. In the configuration sheet, choose “MS-DOS (FAT)” for the Volume Format, and “Single Partition - Master Boot Record Partition Map” for the Partitions setting. You can enter whatever name and volume size you like, then click “Create”.



2. Once the image is created and mounted, open it up in the Finder. Create a new folder at the root level of the mounted disk image and name it “CAMERA”. Then, go ahead and copy whatever pictures or other items you want to test with inside the CAMERA folder. This appears to be one particular camera’s way of storing photos on its memory card - there are a whole bunch of others (”DCIM”, “Photos”, “Videos”, etc.) that would work equally well.
3. Click the eject button in the Finder, then double click the image file to mount the image again. If everything is set up correctly, the act of mounting the image should cause Image Capture to fire up whatever application you have set to handle your digital cameras (e.g. iPhoto), and the images you put in the CAMERA folder should appear in the list of photos for the device.

Not only does this save having to plug and unplug a device whenever you’re doing testing with Image Capture, but it’s also really nice for test suites, since you can just include the disk image as data for your tests, and then mount the image to simulate plugging in a camera.

The first restriction is, of course, that you must distribute your application through Apple’s App Store and iTunes, and Apple gets a 30% cut for their efforts. That part actually isn’t totally bad, since you do get a lot of benefit for being listed on the store without having to deal with any of the setup or maintenance. Sole distribution through iTunes helps with the integration that gives the iPhone such a good user experience, and 30% isn’t an unreasonable cut for Apple to earn on each sale.

The real problem though is the fact that Apple is the sole arbiter of what applications get accepted and rejected from being listed on the App Store. This would be somewhat bad if there were a concrete set of guidelines that said what was and wasn’t acceptable for inclusion. There are some rules outlined in the SDK agreement, but there are apparently also a lot of other “unwritten” rules that are governing Apple’s decision on whether to accept a specific application. Apps have been denied/pulled for UI compliance reasons, for resource usage, for “taste” (e.g. the “Pull My Finger” app), and for no particular reason other than some vague assertion of “usefulness” (e.g. the “I Am Rich” app which cost $999 and did nothing).

The latest app to be rejected takes things over the top, though. Podcaster, an iPhone app designed by Almerica, was rejected by Apple because it “duplicates the functionality of the Podcast section of iTunes”. Forget the fact that this isn’t even functionality that’s only on the desktop application, iTunes. What Apple’s saying here is that they can claim exclusive rights to ship applications for certain domains of functionality, and reject any third party application that tries to compete in that area.

Want to make an e-mail application for the iPhone? Too bad! Apple’s already got one, so you can’t duplicate that functionality. Music player? Nope, sorry, can’t do that either. Or what if, for example, you already have an application selling on the App Store, and then in a software update, Apple decides they want to offer similar functionality. Can they then boot your app from the store, since it’s duplicating what Apple’s done? And what does this do for the power of competition among iPhone applications? It’s a very chilling effect.

Now, it’s perfectly possible that this was a one-time screw up by one Apple reviewer. I really really hope it is, and that Apple clears this up as soon as possible. But regardless of what happens in this specific instance, the real problem here is that there is no clear and definitive list of rules for what will and won’t be accepted to the App Store. Even internally, Apple doesn’t seem to have one, since some apps are rejected for a particular reason, while other apps are accepted that could have just as easily been rejected for the same “offense”.

Before I even think of sinking time into developing an iPhone application, Apple needs to come out with a published (at least to developers who agreed to the SDK terms, if not fully public), detailed description of what criteria an application has to meet to be included in the App Store. Then, of course, they need to apply those guidelines consistently across all applications submitted for approval. Neither of these things is even close to being done now, and I for one am not going to invest time in developing an application without knowing beforehand whether I’ll even be able to sell the damn thing.

Several different solutions (one example here) have been created for this problem, most of which use some variation of adding an “index” attribute to the child objects which specifies what order the objects come in (i.e. the first object has an index of 0, the next and index of 1, and so on). The tricky part come in keeping the index attributes up to date, but there are several solutions for that which all work pretty well.

The major disadvantage to this approach comes when you have child objects which can be contained by more than one parent object. The classic example of this is a program like iTunes, where you can have multiple playlists, each of which can contain multiple tracks, and the user can arrange the tracks in any order they wish in each playlist. The problem is that there is only one “index” attribute for each track, but each track will have a different index depending on what playlist we’re looking at.

I decided to take a stab at this problem using a new approach, which stores the ordering information for each container object in the container itself, and not in the children. I also wanted this solution to be generic and reusable, so you don’t have to reimplement everything for each relatonship you want to give a custom ordering to.

The solution I came up with is a custom subclass of NSManagedObject called BWOrderedManagedObject, which provides support for imposing an ordering on any to-many relationship the object has. At the end of this post, you’ll find a download link containing the source code for this class, as well as a corresponding BWOrderedArrayController class which provides support for sorting a table view by this custom ordering, and a simple demo showing how to hook everything up.

BWOrderedManagedObject

In order to keep track of what order the objects in a particular relationship are in, we need to store a separate piece of data that provides that ordering. The way BWOrderedManagedObject handles this is to store the ordering in a separate attribute. By default, the key used for this attribute is simply the relationship key with the string “Ordering” appended to it, so for example, if you have a “tracks” relationship, the ordering info for your tracks will be stored under the “tracksOrdering” key.

The ordering attribute should be defined in your Core Data model as a transformable property attribute with the appropriate name. The attribute will actually consist of an NSArray holding NSURL objects, with each URL object containing the URIRepresentation of the NSManagedObject it represents. The URIRepresentation is obtained from the NSManagedObjectID for a given object, and is a simple, persistent identifier that can be used to identify the object and won’t change even when saved to disk and read back again (with one important exception - see below). The order of the URLs in the array is what defines the order of the objects themselves in the relationship.

To actually specify an ordering for your objects, NSManagedObject provides a set of methods that allow you to access, insert, delete, and move objects within the array (objectInOrderedValueForKey:, insertObject:inOrderedValueForKey:atIndex:, etc.). It also provides a mutableOrderedValueForKey: method (similar to Cocoa’s mutableArrayValueForKey: method) which returns an NSMutableArray proxy object which you can use to rearrange objects in the relationship as though it were a plain array. To actually access the ordered values, just use the orderedValueForKey: method, which returns an NSArray containing the objects in the correct order.

BWOrderedArrayController

In a typical NSTableView + NSArrayController setup, sorting is accomplished when the user clicks one of the table view’s column headers. Each column has an NSSortDescriptor assigned to it, which are then passed to NSArrayController, which sorts its contents based on the sort descriptors. However, since sort descriptors function by comparing attributes of the objects themselves, this method of sorting won’t work for BWOrderedManagedObject, because the sort order is stored in the container object, and not the objects being sorted

BWOrderedArrayController fills this gap by handling the case where the user has clicked a column which represents the “natural” ordering of the table’s content. To use BWOrderedArrayController, first bind its “contentSet” binding to your object’s content just like you would with a normal array controller. Then, in your table view, select the column you want the user to be able to click to sort the content by their custom ordering.

Instead of binding this column’s “value” binding like your other table columns, instead switch to the attributes inspector pane and enter the name of the ordering key that your content’s ordering is stored under in the “Sort Key” field. For example, if you’re displaying a list of tracks that’s stored in the “tracks” key of the selected playlist, you would enter “tracksOrdering” in the Sort Key field.

If everything is hooked up correctly, clicking that table column will sort the content of the table based on the ordering specified by the user. Performing actual rearrangement of items via drag and drop is not implemented in BWOrderedArrayController itself, but in the project download, an example of how to implement reordering is given in the MusicLibraryDocument class

Inner workings

Most of the nitty gritty of how the code works is documented in comments in the code itself. The tricky parts were:

• Making sure that objects added via both the normal Core Data KVC methods and BWOrderedManagedObject’s methods are both handled properly
• Supporting saving and loading of data, which is made tricky by the fact that newly created objects are assigned temporary IDs which need to be swapped out for permanent IDs when the data store is saved to disk.
• Working out the array controller bindings so that everything would “just work” when binding the contentSet of the controller.

Using the code

The code is freely available under the MIT license and can be downloaded from this link. The download consists of an example project which demonstrates a very very basic data model with two entities: Playlist, and Track. The Playlist entity has a to-many “tracks” relationship and a “tracksOrdering” property to contain the ordering information. The demo is a document based app that lets you create new playlists, drag files from the Finder into the track list to add them, sort the tracks in order, and rearrange the tracks in the list via drag and drop. The idea is loosely modeled after iTunes, but the demo doesn’t actually filter out non-music files, or play music, or anything else useful. It is a demo, after all.

The BWManagedObject class can be used as-is and has no dependencies, and BWOrderedArrayController only depends on BWManagedObject, so you should be able to just add them to your project and compile them (do make sure to link to CoreData.framework, of course).

I have not yet tested this code extensively, so use at your own risk. In particular, I have no idea yet how it performs with larger data sets or other variations in configuration. I welcome all feedback and bug reports at bwebster@fatcatsoftware.com. If I get enough interest, I may even put the code up in a public VCS of some sort, for now I’ll stick with the zip file.

The code will only work on OS X 10.5 and later, the primary reason being that transformable attributes are only supported on Leopard, which is what the ordering attribute must be defined as. This is possible to do under Tiger as well, but requires a lot more code, which I didn’t feel was worth the time to write. Apple outlines what needs to be done in their documentation though, so it should be possible to backport if you need it to work under Tiger. Most of the other code should be mostly Tiger compatible (it doesn’t use new ObjC 2.0 features, for example), but may contain other Leopard gotchas.

• Create multiple iTunes libraries and switch between them easily
• Keep track of a separate music folder for each one of your libraries
• Let you copy playlists and tracks between libraries without losing iTunes data such as play counts, ratings, etc.
• Merge multiple iTunes libraries together into one
• Easily share libraries and music folders among multiple users on your machine
• Find dead tracks in your library whose files have gone missing and hook them back up or delete them
• Clean up your music folder, finding orphaned music and video files that aren’t in your library

It’s very satisfying to finally ship, especially after having worked on PowerTunes in one form or another for about a year and a half now. It’s been my number one request from existing users of iPhoto Library Manager and it’s been something I’ve wanted to do for quite a while.

As is always the case, I had way more feature ideas than I could possibly hope to implement in a 1.0 release (otherwise it would never ship!). In deciding the feature set for the program, I tried to concentrate on things relating to file management. There are plenty of things I could have done involving messing around with editing tags and such, which is a very common need, but is also already covered by a lot of other apps out there. My hope is that PowerTunes’ feature set is unique enough to be useful to many iTunes users, even if they already have one or more other iTunes helper programs.

The development process was, as always, enlightening, and I definitely plan to write up a couple blog posts exploring some aspects of developing this program. The most interesting thing overall is the program’s similarity in function to iPhoto Library Manager. This allowed me to reuse a bunch of code from iPLM, but it also gave me the opportunity to look back at the way I did some things in iPLM and reimplement them in new, better ways. The result of that is now giving me an overwhelming urge to tear up iPLM’s internals and redo it to match the way things work in PowerTunes.

So, go ahead and give PowerTunes a try! The program has a 30 day trial period during which all features of the application are fully accessible. After that, you’ll still be able to do the most basic things like open up your existing libraries, but most of the advanced functionality will be turned off until you get a license for the software.

And in case you’re wondering why I chose the name “PowerTunes” instead of, say, “iTunes Library Manager”, the answer is a) there is already a product with that name, and b) I learned my lesson with iPhoto Library Manager, whose name is really way too long. I mean come on - 9 syllables? What was I thinking?