I’ve never seen anything get so much TUAW-tention. Hopefully it calms down soon. I like TUAW, but this felt slightly spastic.

update after a nice nights sleep:
I haven’t felt this stupid in a while. The problem was that I was building and attempting to debug in the “Release” build configuration. Doh. Breakpoints don’t work when debugging release. I’m sure this burns a handful of people. Too bad Xcode couldn’t see me loading a release built binary into gdb and popup a nice “hey bozo, you sure?” message. Oh well, all is better now that I switched back to debug. I’m not sure how I switched to release to begin with. I have a separate sandbox for doing those tests.

[1] I guess I should be happy that NSLog is working

It was about a week ago that I received the iPod from amazon, charged it and let it do it’s super lengthy sync (5GB’s of music, some video and 5700 photos took quite a while (guestimating it was about two to three hours)). At the end of the sync I made sure that the home movies I encoded and imported into iTunes via my app were indeed viewable on the iPod and they looked great. I then continued to snag some other content to play with via iTunes. Note: If you like stupid things and are looking to waste two or three minutes of your day, I suggest AskANinja.com. It cracks me up (at least the episode titled “roger” did), but I’m told from others that it’s really not that funny. Oh well, on with the post.

After a day or two I noticed the battery life was horrible. I’d listen to an audio podcast on my ride home from work and when I got home, I’d turn on ‘hold’ and then leave the iPod in my jacket pocket sitting idle. When I woke up in the morning the battery was dead!? Coincidentally, the same day I started coming to terms with the poor battery life, I found “How to accurately determine your iPod battery life” in NNW via Hivelogic Links. I ran the suggested test and my iPod’s expected 14 hours of audio playback turned out to be just over 3 hours. I ran the test again this morning with the identical results.

Now it’s time to try out Apple’s “iPod Service Request”. I’ll post my results as they happen, but from the looks of it I expect it to be as easy as:

• Apple sends me the packaging to ship the unit back in (pre-payed)
• I package it up in the supplied box and send it to Apple
• Sometime later I get some other iPod back.

Unfortunately it seems the iPod they send back could be a refurbished model. That would be sad, but somewhat understandable. Not sure if I would know or not. Hopefully not. I’d much rather just assume it was a brand new replacement unit.

Longer version:
I recently added Growl support to my app. It was super easy. I snagged the Growl source, built the Growl.framework and followed the online dev docs for cocoa. Fifteen minutes later and I was done (seriously). Little did I know, I was being deceived. This morning I did a release build for the first time and ran into some issues. The first problem was easy, I wasn’t linking with Quicktime.framework. I’m not sure how debug builds got away with this, but oh well. The second issue was slightly more interesting. I got this error message from the linker:

/usr/bin/ld: warning ../build/Deployment/Growl.framework/Growl 
    cputype (18, architecture ppc) does not match cputype (7) 
    for specified -arch flag: i386 (file not loaded)

Wah!? I’m pretty sure I hadn’t built Growl or my app as a universal binary, but I double checked. Both project’s architectures were set to $(NATIVE_ARCH). I couldn’t figure it out.

After some grep’ing for i386 in my project directory I found my apps release configuration was being compiled for i386, regardless of the project settings shown in Xcode. I triple checked the xcode project settings for all configurations and even explicitly set ‘ppc’. Regardless of the setting, i386 was always in my .pbxproj file. What’s one to do? I closed my project in Xcode and removed the i386 by hand. Re-open in Xcode and all was well. My app linked as release with Growl just fine.

To confirm what I was seeing I created a new Cocoa application in Xcode. I confirmed the project settings for both release and debug were set to only build for $(NATIVE_ARCH) and did a release build. All went well. Now I checked the .app file in Finder and sure enough, it was built for Intel, PowerPC. Weird. Is this a bug? Is Apple trying to trick us into building new apps as universal binaries? My guess is it’s a bug, and potentially just a bug in my environment. I did a little digging, but couldn’t find anyone else complaining about this. Oh well, at least now I know.

update: Luis de la Rosa of WebnoteHappy fame was kind enough to try to reproduce this for me. His results were better. Although release was building Intel by default, the architecture setting for the project made it clear that that’s what was going on. When he unchecked i386 it stopped compiling for i386 (how nice). So, one has to assume it’s something in my environment somewhere causing this.

The goal is to dim the display as the surroundings get darker. This is an admirable goal. The display doesn’t need to be nearly as bright as the space your in gets darker. Unfortunately, the implementation is somewhat annoying. The problem is that when my ambient light is just beginning to get low, the display’s brightness seems to slosh slightly between a little darker and a little brighter. This drives me nuts. The solution should have been to turn off “Automatically adjust brightness as ambient light changes” and I’ll manage the brightness myself. All is well, right? Nope. I’ve turned this feature off at least four times in the past couple months. More annoying than the sloshy brightness is the fact that the setting is being reset somehow. Now that I’m convinced it’s turning itself back on, I’ll keep an eye on it and look for a pattern.

I decided to do three minutes of “research” on this issue. Turns out I’m not alone: macosxhints – Work around an ambient light adjustment bug in 10.3.8
In that article someone states:

I tried too turn off “Automatic Adjustment … ” in Display Preferences but the checkbox allways[sic] turned on again when reentering the preferences (???)”

This comment was from Feb. 28 ‘05. I guess I shouldn’t hold my breath for a fix. Oh well, all things considered, it’s a minor issue.

In a less negative tone, look at this slider bar pulsate at you when you have “Automatically adjust brightness as ambient light changes” turned on: System Preferences Movie