iPhoto 7.1 update

Posted on September 27, 2007 by Brian Webster
Filed Under News, Updates, iPhoto Library Manager | Leave a Comment

Naturally, since I released an update to iPhoto Library Manager yesterday morning, Apple had to go and release an update to iPhoto about 5 hours later that broke some stuff. Worst. Timing. Ever.

A few things needed tweaking to maintain compatibility, but it wasn’t much, and I’ve posted a new update to iPhoto Library Manager (now version 3.3.2) to get everything working properly with iPhoto 7.1 You can download the new version from the main iPLM page.

iPhoto Library Manager 3.3.1 released

Posted on September 26, 2007 by Brian Webster
Filed Under News, Updates, iPhoto Library Manager | 1 Comment

iPhoto Library Manager 3.3.1 is now available for download, incorporating several bug fixes and a couple of new iPhoto 7 specific features. The new version is a free update for existing iPLM users, you can just download the new version and replace your old one with it. There were a couple common problems that people were running into with iPhoto 7, which should be alleviated somewhat with this new release.

iPhoto 7 seems to be a little flakier that previous versions when it comes to properly updating thumbnails for photos that have been edited. The thumbnail would end up reflecting the original version of the photo instead of the modified version, making it appear that the modified photos had not been copied over at all. I’d seen this happen on occasion with iPhoto 6, but it seemed to be become much more common once people started upgrading to iPhoto 7, and this update should hopefully prevent this from happening anymore.

iPhoto 7 adds the new ability to hide selected photos in your library, to help you be able to navigate your library and ignore photos you don’t need to work with at the moment. iPhoto does have an item in its View menu that will let you show/hide the photos you have marked as hidden, so you can still reveal them if you need to, then easily hide them again. However, iPhoto does not write out information for hidden photos to its AlbumData.xml file, which is what iPLM reads to display the library’s album list in its window, and is also used by iMovie, iDVD, Pages, and many other applications to let the user easily use their iPhoto photos in those applications. This behavior occurs even if you have elected to display your hidden photos in iPhoto’s interface, so there is no way to access hidden photos from other applications.

I actually filed a bug with Apple on this issue. The good news is I got a quick response, but the bad news was the response was “Behaves Correctly”. Grrrr. The explanation:

“The View > Hidden Photos option is to allow users to manage their hidden photos (photos marked hidden) without inadvertently making them available to other applications.”

So this means that if you want to access photos from another application that you’ve marked as hidden, you need to actually unhide those photos, go do your thing with them, then come back to iPhoto and mark the photos as hidden again. Of course this means that you get to be the one to keep track of exactly what photos those were, then go find them again in iPhoto to re-hide them. Needless to say, I think this is exceedingly silly, especially since the View > Hidden Photos option would allow you do exactly the same thing with much less hassle. I’d encourage anyone who’d like to see this behavior changed to provide feedback to Apple, either via bug report or the iPhoto feedback page. And as always, be polite. :-)

But, the good news is that hidden photos are still accessible via Applescript, so iPLM 3.3.1 adds an option that will copy hidden photos, and also re-hide them in the destination library after they’ve been copied over. There are some other goodies in the new version, and you can find the full list of changes on the release notes page.

Subclassing NSSortDescriptor for fun and profit

Posted on September 7, 2007 by Brian Webster
Filed Under Cocoa, Programming, Development | Leave a Comment

In the project I’m currently working on, I’m using a pretty standard NSTableView + NSArrayController setup using the default sorting functionality. However, I found myself wanting to do some custom sorting, i.e. not just the usual sorting provided by @selector(compare:). This is made a little more complex by the fact that the columns of the table can be dynamically added and removed, so it’s not quite as simple as just changing the sort selector in Interface Builder. On top of that, I later found that I needed more customization still, because I needed to do special handling of nil values that was different from NSSortDescriptor’s behavior.

So, I set off to make a custom subclass of NSSortDescriptor. I can just override compareObject:toObject:, easy as pie! Right? Er… not quite. There really isn’t any information at all in the Cocoa docs about subclassing NSSortDescriptor, and there are a few gotchas that aren’t necessarily obvious when implementing the subclass, especially if you’re using it with an NSTableView.

To begin, I made my subclass (ITSortDescriptor) and overrode the compareObject:toObject: method. This worked fine to begin with, but I discovered that if I clicked on a table column to change the sort order of the table, it would soon revert to the default sort behavior. After some debugging, I discovered that the reason for this was that NSTableView was making copies of the columns’ sort descriptors using the NSCopying protocol. NSSortDescriptor implements NSCopying, but apparently its implementation will always return an instance of NSSortDescriptor, even the object being copied is an NSSortDescriptor subclass. So, I implemented copyWithZone: in ITSortDescriptor to return an instance of the subclass rather than a plain NSSortDescriptor. The implementation is pretty straightforward:

- (id)copyWithZone:(NSZone*)zone
{
return [[ITSortDescriptor alloc] initWithKey:[self key] ascending:[self ascending] selector:[self selector]];
}

This solved the problem for some cases, but there were still times when the column would revert to its old sorting behavior. I narrowed it down to when the table was already sorted by the column in question, and then you clicked on that column again to reverse the sort order. Apparently, NSSortDescriptor’s implementation of reversedSortDescriptor suffers from the same problem as its implementation of copyWithZone:. Overriding that in a similar manner then fixed that problem:

- (id)reversedSortDescriptor
{
return [[[ITSortDescriptor alloc] initWithKey:[self key] ascending:![self ascending] selector:[self selector]] autorelease];
}

To be really cool, instead of having [ITSortDescriptor alloc], that could instead be [[self class] alloc], but that would only really be useful if that’s what NSSortDescriptor did itself.

So with those modifications, I now have my table sorting just the way I want it. I thought I’d blog this so that anyone else who came across this stuff and was banging their heads against the wall might find it and save themselves some pain.

Feed