Being PowerBook based, I was a bit disappointed. The towers sound fantastic, especially the G5 Quad, which is a mind-blowing amount of horsepower in a desktop machine. Aperture looks stellar, I know several professional photographers who will probably start using it right away and I might be graduating from iPhoto too.

Today’s hardware releases had to have been tailored for a few goals:

1. Make terrific machines which will sell
2. Don’t exceed the Intel machines
3. Don’t fall too far behind the Intel machines

Number one is obvious. Numbers two and three are more delicate. These machines can’t be so good that they take the piss out of the coming Intel boxes. Likewise, they can’t be so pathetic that Intel hardware makes these worthless. Apple has a great deal invested in brand loyalty, these machines were distinctly tailored for the transitional role they’ll be serving.

Based on that, i think it’s clear that the PowerBooks are maxed out. Yes they have better screens, better batteries, upgraded video chipsets, dual-layer DVD burners, digital audio ports and the option for larger hard drives. But there was no speed boost. These are the same CPUs as the previous generation — and that’s why I’m not going to buy one now.

New portables will most likely ship before new towers. Intel’s latest quarterly earnings pointed to the exceptional performance of their portable division. Before this upgrade, PowerBooks hadn’t been updated since January 2005, which means that Apple’s laptops for the holiday season will likely be running year-old CPUs. That’s just bad on its face. Intel’s Mobile Computing Platform and Centrino chips have been an area of great innovation at Intel, a good thing since AMD’s workstation and server chips are currently out-performing Intel’s equivalents. Apple’s Intel laptops are likely going to break my third point above. Battery life should be significantly improved and there will probably be something close to a half gigahertz speed increase (numbers based on the Intel® Products Laptop Processor Roadmap). This round of laptops won’t compare well unless Apple releases intentionally weakened Intel PowerBooks.

So I’m thinking 1Q 2006 for laptops, hopefully at MacWorld in January. They will absolutely be shipped at least a month or two before WWDC. There’s no way Jobs will get onstage this year without having shipped Intel laptops. A few months lead time would allow many developers to have Intel hardware on their laps for the keynote.

I just posted updated versions of my iPhoto AppleScripts which hopefully address many of the problems related to System Events errors.

As I was trying to nail down what caused System Events to throw occasional errors I found a bug which was my fault. If any other windows were open in iPhoto, (info, keywords, Keyword Assistant), iPhoto would sometimes throw an NSReceiver error. All extra windows will now be closed before setting any dates. Apologies for not catching that sooner or thinking to check whether other windows were open. Hopefully that oversight will account for the majority of NSReceiver errors.

All window references should now be numeric, even though I’m fairly sure the window is always called “iPhoto” despite the active user language. (I deduced that from running the application under a variety of languages while internationalizing the date handling, the window title was always “iPhoto” even if everything else was not English and using non-Roman characters.)

iPhoto is now more assertive about coming to front, this should make running from Script Editor easier since dialogs won’t be popping behind iPhoto.

Every System Events command is now wrapped in an try block and a loop. Errors will cause that function to be run again after restarting System Events. I did this in the functions to try and maintain portability, but it made the code much uglier.

Random notes:

iPhoto 5’s adjustment windows are wacky. They report themselves as “AXUnknown”, with a possibly English localized name “HUD”. These windows do not respond correctly to a close window command

iPhoto 4 and iPhoto 2 reversed the numeric index of the date and title fields in the info pane. I must the only person in the world who noticed that. If I remember correctly there was no iPhoto 3. iPhoto 2 is not currently supported, for whatever reason it wasn’t correctly incrementing selections via Apple Events. If it’s a quick fix, I might get that working at some point since I have access to a machine with that version.

After a ton of testing and waves of frustration, I think this is finally ready to test again.

UIcheck() System Events Test Script 2 (UIcheck-100605-1525.zip, 10k)

Again, please run this and let me know what your results are, including OS version and a vague hardware description.

A few observations:

The script is much larger, but the re-useable parts are fairly self-contained. Most of the size comes from error logging and timing functions. Please feel free to pilfer whatever you want from this example.

One of the biggest problems noted by the previous test script was -609 “Connection is invalid” errors. Thanks to a great post and followup by Bill Cheeseman on the CocoaBuilder site, I figured out why those were happening.

Essentially, AppleScript was sending commands to an application which wasn’t ready yet or that was shutting down. For whatever reason, AppleScript doesn’t necessarily clear the reference to an application that’s been sent a quit command. It’s possible, and quite likely that sending a command to an application immediately following a quit command won’t restart the application, it will cause a -619 connection error since AppleScript will try to send the command to the vanishing application.

Additional testing proved that hypothesis. Several other applications all threw -619 errors when cycled too quickly. So these errors weren’t the issue. There were still occasional “-50 Parameter error” errors, which seem to occur randomly whenever sending a command to System Events. These appear to be the most traceable problem I’ve found.

That noted, System Events seems incredibly slow to quit. On 10.3.9 it requies two tries almost every time. After testing some delay statements to pause the script, I ended up looping around a try statement which quits and re-launches the application. If the application responds correctly, the try doesn’t fail and the repeat is exited.

Hopefully this will continue to work. In testing I found the scripts seems sensative to humidity, mean looks, cute girls and smelly lunches. They’d work one day and fail inexplicably the next. This iteration however, seems to be working.

The next step is to build in an error-catching loop into the iPhoto date setting routines to make sure the script doesn’t fail and skip over any photos.

Previous posting on this topic is here: AppleScript System Events Bug

Update Thanks to everyone who helped test this, I’ve rolled these functions into my iPhoto AppleScripts which should be more robust now.

Despite the number of people successfully using my iPhoto AppleScripts, I’ve had a troubling number of people report problems as well. These weren’t just little problems, the scripts completely failed to run.

I asked several of these people to run the scripts from Script Editor and send me the error message they got when the scripts failed. All but one of the problems happened during a call to the System Events background application. Most infuriating was the fact that I couldn’t reproduce the problem. Today I managed to recreate what I believe is the problem.

The script below is a test script which pounds on System Events then tries to detect and recover from System Events crashes.

UIcheck() System Events Test Script (UIcheck.zip, 4k)

Please download the script and post your results in the comments. I’m seeing a consistent 3-9% failure rate for System Events on my PowerBook.

This is public domain, use at your own risk, etc. Please post improvements if you have them.

Update: Please post your OS version alongside any results.

Update 2: More on the System Events AppleScript bugginess Including a new test script.

Joe’s iPhoto AppleScripts for Date Manipulation have been updated. I’ve been working on these for a while towards the goals of making Automator actions and a standalone Application, but some unknown incompatibility introduced by iPhoto 5.0.4 pushed this to the front burner.

Some areas of improvement:

• Better UI Date Entry – Dates entered directly in info pane, no more popping the Batch Change window
• Language Independence – All language specific UI calls removed, should work with any language or date format
• Date format sniffing – The date format is now discovered gracefully and checked for accuracy.
• Faster – Extensive refactoring and efficiency tuning, now I can really blame iPhoto for the slowdowns.
• Works with iPhoto 5.0.4 – I’ve been testing it all evening with absolutely no problems (I probably shouldn’t say that)

I still don’t know why the previous scripts stopped working with 5.0.4, but I was thankfully able to get these all working with the newest iPhoto in a few hours this morning. Good application design really does make a difference. I know I’m still not working in true OOP, but breaking the code down into simple, self-contained chunks really makes maintenance simpler. The return curve (that agonizing time spent staring one’s own code and having no idea how it works) is much shorter when each component is named descriptively, has a concise, easy to grasp function and doesn’t draw from anything but it’s explicity input parameters.

Idea for next time: If these scripts obliterated the existing clipboard, would that be a dealbreaker? Or just an annoyance? What if they ran a lot faster?

I’m looking for a way to save and restore pre-existing clipboard data.

I have a few Studio projects that use UI scripting. Sending text to a non-scriptable control by pasting from the clipboard is significantly faster than using the Keystroke command. What I’d like to do is store the complete contents of pasteboard “general”, execute my UI stuff, then repopulate the pasteboard with the archived values.

Because my goal is to leave the clipboard data as I found it, this needs to work with any kind of clipboard data. The problems I’m having relate to complex data being dumbed down. For example, an image copied from Safari becomes a plain text URL after storing and retrieving. Conceptually, moving a big lump of data should be possible, regardless of supported formats.

One other related question: Is the list returned by types of pasteboard “general” prioritized? If I had to pick one of the returned types, how would I know which was best?

MacScripter: Store and Retrieve Pasteboard

Anyone have an idea about this one?

10.4.2 is out, apparently the iPhoto Color Shift Bug was not fixed.

update: FIXED! (iPhoto 5.0.3 update)