• 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?

So, what exactly are the problems that vex Applescripters so? There are quite a few, but here are some of the ones I can think of.

Lack of basic language features

Many modern scripting languages come with a fairly hefty set of built in data types and functions (or classes and methods for OO languages) that support a wide array of built-in functionality. Applescript has its own set of functionality, but for many standard tasks, it frequently either lacks the ability to do so at all or supports things but in a very hard to use or unintuitive way. A few examples include:

• Sorting an array of strings: Javascript has Array.sort(), Applescript has nothing.
• String manipulation, such as splitting strings apart, easily extracting substrings, etc. Some of these things can be done in Applescript, but are much much harder than they should be. (How many people know about “Applescript’s text item delimiters”? OK, both of you can put down your hands now)
• Mutable arrays/lists. Applescript lists support some operations, such as concatenating two together into one, fairly easily, but good luck if you want to do far out things like inserting a new object into the middle of a list, or delete an item from a list. Most of these things involve twisting yourself in a knot, splicing lists apart and back together again.
• Mutable dictionaries/records. See above.

This is just a small sample, I’m sure there are many other things that are pretty standard in other languages that are absent from Applescript, or hidden away in the Standard Additions scripting dictionary somewhere.

File references are the devil

There are at least 5 different ways I can think of to refer to a file using Applescript (alias, POSIX file (a.k.a. file URL), Finder style object specifier, POSIX path, Carbon path). Different applications use different data types in different places, and will often barf back errors if you don’t use just the right kind of file reference. Figuring out how to translate from one kind to another is often maddening. Here’s an example from one of my own scripts, which uses three of the five types in a single line:


set helpFolderPath to POSIX path of ((folder “Help” of folder “en.lproj” of ptFolderAlias) as alias)


Files really need to be treated as first class citizens, with support built in to the language, and without needing to rely on the Finder for all file system access. Or wait, am I supposed to rely on System Events now instead? Or maybe a “do shell script” call to ls on the command line? Oh, the pain.

Scripting dictionaries

This is one of the biggest hurdles that a lot of beginning scripters have with Applescript, is understanding how scripting dictionaries work. Tools like Script Debugger are extremely helpful when it comes to exploring an application’s dictionary (I hardly look at the dictionary anymore these days, and just go right to the explorer pane and start drilling down), but while $199 is a fair price for a developer, most people aren’t going to want to drop that sort of change just to learn Applescript. Script Editor did get a pretty good upgrade in Tiger, but I think it needs more work to help beginning scripters understand how to explore and use scripting dictionaries.

The death of recordability

Another invaluable tool for beginning scripters which is all but dead is application recordability. Back in the OS 9 days, you could hit the “Record” button in Script Editor and go perform operations in other applications, and the equivalent script commands would magically appear in Script Editor. This was a great way to quickly learn the commands to use to do certain things you already knew how to do using the GUI of the application. Since OS X, recording has basically gone away. The only applications I know of that are still recordable are the Finder and BBEdit/TextWrangler. Cocoa has zero support for recordability. Theoretically, you can use the Carbon APIs to do this still. I actually tried once, and gave up after a couple days of banging my head against the wall. I’d love to see recordability come back, with a whole new approach if necessary, with full Cocoa support.

Applescript does have a lot going for it, but is hamstrung by a lot of these types of issues and prevented from reaching its full potential. Replacing it with another language is one way to go, but fixing Applescript also has a lot of potential. This above list is just a sample of some of Applescript’s shortcomings (if you have your own pet peeves, feel free to express them in the comments). The idea of redesigning Applescript from the ground up, with nearly 20 years of experience to build on, is very appealing, but who knows if Apple will ever have resources to devote to a project like that.

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.

The basic idea behind PowerTunes is quite similar to iPhoto Library Manager: instead of just having one monolithic iTunes library where you dump all your music and video, you can instead split your stuff up among multiple libraries and switch between them. This can be useful for simple organizational purposes, and can allow you to do things such as allow multiple people to keep separate iTunes collections (and sync them with their respective iPods) without having to go through the hassle of setting up multiple user accounts to do so.

Like iPhoto Library Manager, not only does PowerTunes let you set up multiple libraries, but it also offers additional features that let you copy music and playlists between libraries, organize multiple music folders, clean out unwanted files from your music folder, fix dead tracks in your library, and much more.

iTunes 7 actually added for the first time the ability to place your iTunes library file in a different location from the default location by holding down the option key when you launch iTunes, just the same as you can in iPhoto (previously, the only way you could shift your iTunes library location was by using aliases and such). PowerTunes actually utilizes this mechanism itself, and thus requires iTunes 7 or later. Unlike iTunes, PowerTunes also ties each library to a particular music folder, so if you have music stored in separate places, it will switch the music folder location along with the library location when you change back and forth.

The main reason for want to have some other testers before a final release is that there are many possible ways one could go about setting up their iTunes libraries and music folders, including putting stuff on external hard drives, accessing stuff over file sharing or an Airport Disk, and so on. I’ve tested as much of this as I can, but there will always be setups I either can’t test or haven’t even thought of.

So, if you’re interested in helping to test PowerTunes, I’ve set up a form that you can fill out to sign up for the beta. I don’t know how many testers I’ll need or how long the testing period will take at this point. If everything works fine, it could be as brief as a couple weeks, or it could take longer if more things need fixing. So, depending on how many testers I need, not all those who signup will necessarily become testers.

Like I said before, I’ve done a lot of testing so far, but the possibility of bugs occurring still remains, so all testers will be encouraged to back up their iTunes library and music, just in case. Those who do help in testing will get a free PowerTunes license and the thrill that comes from running beta software.

So, if you’re interested, head on over to the signup form and sign up to be a beta tester. Oh, and I almost forgot, a couple obligatory screenshots.

Also be sure to check out the Extended Deals page, which lists all the products that have been featured so far in the month, and you can still get 10% off any of those products by using the coupon code MACSANTA07TEN anytime until the end of December (this also applies to iPhoto Library Manager and PlistEdit Pro after today). There is also an RSS feed available, so you can continue to keep up on new deals that appear between now and Christmas.

The jist of the article is that the author, Ankur, needed to draw some gradients in one of his applications, downloaded the source code for CTGradient, an open source library that provides a class to draw various types of gradients, and decided that it had way more functionality than he needed in his own program. So, he went through the code and basically removed everything he didn’t need for this single application. That’s all fine and good, and the article is actually an interesting look at performing various refactorings and dead code removal.

The problem arises in that he implies that if a developer decides to use some open source code and doesn’t go through and strip out every ounce of functionality that they’re not immediately using, that means that they’re encouraging “code bloat” and that their code is not “optimized”. Several commenters asked what kind of performance/memory gain he actually saw, and the only numbers he provided were from the “Real Memory” column in Activity Monitor, which is a pretty crude measure. The conversation went downhill from there.

I think one main point of miscommunication here is over the terminology the original author uses for some of the things he’s talking about. When you talk about “optimizing” code, I, and most other developers I know of, think of making the code run faster. The author reinforces this by stating “…you can optimize this thing till it runs like a Ferrari”. Certainly sounds like he’s talking about making the code faster, but the vast majority of what he’s doing is simply stripping out code that he’s not going to be using. This has pretty little effect in and of itself - it saves a few KB in disk space, and if the code truly is unused, it probably won’t even get paged into memory in the first place. There are a few places where the code probably runs faster, but the gains look pretty minimal in the big picture. However, arguing the nitty gritty details about his particular optimizations is missing the bigger point…

Engineering is all about tradeoffs, and in computer software, this typically means choosing between things such as memory usage, disk usage, CPU usage, and so on. Every one of these, however, inevitably comes up against the restraint of development time. You can spend days, weeks, or months optimizing your code in various ways, but it’s all for naught if you don’t eventually ship your application. This means that you can’t do everything, and have to pick and choose what areas of your code to work on, whether to add new features or shore up existing ones, and how much time to spend optimizing performance and memory usage.

What is conspicuously missing from the article is any sort of evidence that CTGradient was actually causing any sort of performance or memory problem in his application in the first place. Now, may more have gone on that he didn’t include in his write-up, but it sounds like he simply looked at the code, decided that it was obviously too big and bloated, and set to work spending quite a bit of time hacking it down to the bare minimum he needed.

Finding and fixing performance and memory problems in real applications, however, is rarely so simple. It’s rare that you can glance at a piece of code and immediately deduce that it’s going to be problematic for your application, causing slowdowns or whatnot. Most such bottlenecks are discovered as a result of rigorous testing, using tools provided by Apple such as Sampler, Shark, and Instruments (among others) to dig into the details of what your app is actually doing and where it’s spending its time. Upon discovering such a problem, you can then go in and spend your precious time fixing what most needs to be fixed. It’s not that the modifications he makes don’t actually reduce code size and memory footprint (they do) or increase performance (still not really sure about this without empirical data), but with testing first to find what needs fixing, the time spent doing all this could very well have been better spent fixing something that actually needs fixing.

I actually use CTGradient in a couple of my projects, and I use the code basically untouched. This is not because I’m “lazy” and would rather count my customers’ money while cackling evilly than spend the time to strip out everything I don’t use, but rather because I have plenty of other things to spend time on, optimizing my app in ways that make a difference, and adding features that people want and need. None of my tests of my drawing code have ever shown any performance problems arising from using CTGradient as-is, so my motto is, if it ain’t broke, don’t fix it. The critical flaw in Ankur’s argument in his post is that he never showed any evidence that anything was broken in the first place.

• I have a build script that I use to assemble the disk image for a new release of iPhoto Library Manager or PlistEdit Pro. The script creates the disk image using the hdiutil command line tool. Everything went fine when building under Leopard except that, if you tried to mount the disk image on 10.3.9, it would refuse to mount. It turns out that Leopard’s hdiutil, when running on an Intel machine, now defaults to creating an image with a GUID partition table rather than an Apple partition map like it used to. 10.4 and 10.5 can handle this fine, but 10.3.9 can’t and thus refuses to mount the image. The solution is simple: just pass -layout SPUD as an additional argument to hdiutil to force it to create an Apple partition mapped image.
• One of the first thing many Cocoa programmers do when starting up a new project is to add a breakpoint on -[NSException raise]. This makes it much easier to find out when exceptions are getting raised in your code and debug them quickly. I had this setup already, but when running under Leopard, I was getting exceptions thrown, but my breakpoint wasn’t getting hit. Turns out this has changed (at least for the cases I was seeing) under Leopard, so to experience the new exception debugging hotness, try a breakpoint on objc_exception_throw.
• Similarly, I was trying to break on NSLog to find out where some error messages were being printed out that I couldn’t track down. NSLog wasn’t getting hit, and it turns out that the printout was coming from CFLog instead.

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).

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!

The article uses a recent MacFixIt post on DiskWarrior as an example, and I actually used to work for Alsoft for a few years, and it’s definitely not the first time this sort of thing has happened with MacFixIt. We had to deal with them on several occasions when they posted various stories, mostly regarding DiskWarrior, that either stretched the truth or were just outright false.

It seems that a large amount of MacFixIt’s material comes from reader e-mails and other such input. That’s not a problem in and of itself, but the problem is that there is almost no effort put forth on their part to filter and/or verify the statements made by their readers. The result is that stories go up on the site that have absolutely no basis in reality, simply because one or two readers e-mailed in. “I noticed that when I upgraded my iLife on the full moon, it crashed my machine, but then when I rebooted and tried again when the moon was waning, it worked!” results in the headline “Warning: iLife installer deletes your photos when installed under a full moon!“

MacFixIt seems to hardly ever even bother to try some of these things readers write in about to see if they actually behave as described, but even worse, they often won’t even try verifying something with the developer of an application if a problem is reported with it. This happened several times at Alsoft, where some reader reported a problem with DiskWarrior and blamed it on something, and MacFixIt happily plastered it on their front page as though it were gospel, causing all sorts of people to panic about running DiskWarrior under whatever circumstances they claimed caused the problem. I remember one case in particular where they claimed that DiskWarrior wouldn’t work with Firewire 800 drives (which is utter nonsense), simply because some reader had had a problem rebuilding their own Firewire 800 drive. Of course it turned out to have a completely different cause (a bug in Quicktime), one that had actually already been well documented months ago, on MacFixIt’s own site!.

Had they bothered to simply shoot an e-mail or phone call our way, we could have provided them with the solution, they could have referred their reader to their old article with the solution, and saved everyone a whole lot of hassle. This is not only a problem for MacFixIt’s readers, but it costs the victim company time and money in responding to the resulting support calls and e-mails, plus the effort needed by the company to try to set the record straight.

So, if you’re a regular MacFixIt reader, I would encourage you to take everything they say at least with a grain of salt, if not to stop reading the site altogether. They have journalistic integrity on par with the National Enquirer. And if you do experience a problem with a program, contact the program’s developer. They are often quite helpful and actually know what they’re talking about, and will be happy to help you with your problem. Now if you’ll excuse me, I need to go install Leopard before the tides come in…

• I am currently working on the update, but Apple has decided not to give developers an advance copy of the final version of Leopard until it ships, which means that I won’t truly be able to start final testing until this weekend. I’m hoping that it won’t take too long and that the iPLM update will be out sometime next week.
• Similarly to major iPhoto updates, so far the basic library switching in iPLM seems to work fine in Leopard, it’s just the advanced photo copying stuff that will need additional work, so upgrading to Leopard isn’t going to cut you off from your iPhoto libraries or anything
• The update will be free, so if you buy a copy of iPhoto Library Manager now, you won’t have to pay to upgrade, you can just download the new version.

That’s all for now, I’ll try to keep updates coming as I know more.

Hmmmm, this is seeming awfully familiar… where might I have seen this before?

Yeah, OK, my evidence is a little slim…. so far. But I’ve got my eye on you, Apple!

1. Scriptable System Preferences: There’s all sorts of functionality in System Preferences that I wish again and again I could change using a script. It doesn’t look like everything is scriptable, but it’s definitely a step in the right direction
2. UI Recording and Playback: Back in the day, Applescript used to support recording, which was a great way to set up simple tasks and learn scripting. This has fallen by the wayside in OS X, but I’m glad to see some kind of recordability make it back into the OS, even if it’s slightly less sophisticated.
3. Spring-Loaded Dock: I knew about this before, but apparently in addition to opening folders via the dock, you can also “spring-load” applications. Pressing the space bar while holding a drag over an app in the dock will launch the application. I’m pretty sure I’ll find ways to use this.
4. Finder Path Bar: This is a nice little touch that puts the full path to the current folder in the bottom bar of your Finder window, similar to the one you see when selecting a search result. Simple, but will definitely make life easier.
5. Inline iCal Editing: I never really liked having to shuttle all the way over to a separate window/drawer to edit iCal events. This looks like it will be much more intuitive.
6. iChat Audio/Video Recording: I don’t do audio/video chats that often, but I love having transcripts of my text chats to look back at, and being able to do this with audio/video chats is definitely nice to have.
7. Self-Tuning TCP: One of those under-the-hood optimizations that probably should have been done a while ago, and for which there are multiple third-party ways to enable it. Nice to see this here.
8. PDF Manipulation in Preview: This is sweet, being able to reorder pages in a PDF, or copy pages from one PDF to another. You can combine multiple PDFs into on or split them apart. Preview is really getting to be a pretty powerful little application.
9. Calculations in Spotlight: Finally, I can do quick calculations directly from my keyboard without having to open a separate app or widget.
10. Scroll Non-Active Windows: Another little feature that I’ve found myself wanting fairly often. I sometimes employ the command-drag trick to drag a background window’s scroll bar, but just being able to crank the scroll wheel is much nicer.

Leopard will require some changes in the way iPhoto Library Manager works under the hood. iPLM uses the Input Manager mechanism of Mac OS X to load a bundle of code into iPhoto which supplements iPhoto’s Applescripting capabilities, which is what makes features such as copying albums and merging libraries possible. Some other programs, such as Inquisitor and 1Passwd also use input managers to implement their functionality. However, as has been reported by Ars Technica and discussed on some other blogs, input managers are no longer going to be supported under Leopard.

Other developers have found other methods to do what they need to do under Leopard, such as 1Passwd, whose developers say they are going to switch to a WebKit plugin, which works well for them since their product is web browser oriented. iPhoto Library Manager is going to take a different approach though.

One difference between iPLM and some other apps that use input managers is that iPLM only actually needs its code to be loaded when it’s actively doing something with iPhoto, like copying some albums between libraries. It doesn’t matter if the code is loaded every time iPhoto is launched, unlike say, Inquisitor, which pretty much always has to be there to be of any use.

So, instead of a plugin based approach, under Leopard iPLM will use a handy little feature of the OS X dynamic linker, the DYLD_INSERT_LIBRARIES environment variable. Basically what this does is allow you to load additional dynamic libraries in an application (and even substitute for libraries the application is already linked to). The most well known usage for this feature is the MallocDebug developer application, which loads a custom debug version of the malloc library that replaces the normal system library and provides all sort of information on memory usage in the application being debugged.

The downside to this approach is that it requires relaunching the application in question in order to load the additional code, since you have to set up this environment variable and then launch the application yourself. So, for something like Inquisitor, launching Safari directly from the dock would not load the code automatically. There would have to be a separate program that performs the special setup and launch Safari itself, which would be a pain in the butt for users. However, this isn’t really a problem for iPLM, since it has to relaunch iPhoto multiple times during an album copy anyway, so having to do the special setup doesn’t really change the flow of things at all.

There are a couple other upsides to this approach:

• The code will only be loaded into iPhoto itself, unlike input managers, which load their code into any Cocoa application that runs. iPLM’s code doesn’t actually do anything unless it’s being loaded in iPhoto, but the input manager bundle still shows up in crash reports and such, which can be suspicious to others trying to debug a crash.
• Nothing needs to be installed! All the code can sit happily within iPLM’s application bundle, and there’s no need to update the bundle when iPLM is updated, or any of that hassle. This means I’ll actually be deleting more code than I’m writing in order to change to the new method.

The only feature that will be lost as a result of the change is putting the name of the current library in the title bar of the iPhoto window itself. This was a neat addition that I put in on a whim, but since the iPLM code will no longer always be running in iPhoto, this will be going away.

In retrospect, if I had known about this method of doing things back when I first wrote iPLM 3.0, I probably would have done it this way in the first place, since it’s less intrusive and uses a long standing feature of dyld that isn’t likely to go anywhere anytime soon. Like I said above, this method isn’t feasible for many programs that are currently using input managers, but this may still prove a useful technique to some other programs transitioning over to Leopard.

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.

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.