Archives / Search ›

Er, so much for the DockCam release. Still remaining on the to-do list:

  • Every other time you open Preferences, the focus changes
  • Fix return in combo box not triggering default button
  • Check that we aren't leaking NSURLHandles (or anything else for that matter)

The first issue is a bug in my pref handling code which I haven't tracked down; the second is a bug in NSComboBox which I can probably work around, and the third is what I've spent the past two hours trying to figure out.

According to the indispensible OmniObjectMeter, I'm leaking primarily NSConcreteMutableData and NSHTTPURLHandle objects. Watching my process's memory usage, it grabs about 500K per image load. But if I stop the timer which triggers image loading, lots of memory is freed, and the leaks have dropped to about 10K per load. There's an autorelease pool that is waiting for me to stop, but my program isn't designed to do that.

The NSConcreteMutableData objects are being retained by the NSHTTPURLHandle objects, ironically inside a method called 'flushCachedData'. Some flushing it's doing!

The retain-release cycle of a NSHTTPURLHandle object looks like this:

  • alloc in my code, from -[NSURL URLHandleUsingCache:]
  • autorelease called inside -[NSURL URLHandleUsingCache:] (makes sense…)
  • 2 retains in -[NSURLHandle loadInBackground], called by my code
  • release in my code, because I explicitly pop the autorelease pool used by -[NSURL URLHandleUsingCache:]
  • release in the stream read callback, -[NSHTTPURLHandle performStreamRead:]
  • autorelease in the stream read callback
  • release in -[NSApplication run]

The problem is that the final release is never triggered until the application is quiescent: when I stop the timer that causes the image to reload. For the moment, I'm stumped. My only thought is to switch from NSURLHandle to Dan Wood's CURLHandle in the hope that it will let me control its allocation behavior.

Massinova is back, with a new menu.

DockCam 1.0 release should be later tonight.

Apple no longer even pretends to follow its own interface guidelines. Take the Window menu. According to the Aqua HIG:

Window menu items appear in this order: Minimize, Zoom, <separator>, <application-specific window commands>, <separator>, Bring All to Front (optional), <separator>, <list of open documents>. The Close command should appear in the File menu, below the Open command.

Let's take a sample of some apps which ship with Mac OS X. Here are the items which appear before the first separator.

  • Finder, DVD Player: “Zoom Window”, “Minimize Window”
  • Preview, Stickies: “Close Window”, “Miniaturize Window”
  • Installer: “Close Window”, “Zoom Window”
  • QuickTime Player: “Zoom Window”, “Minimize Window”, “Bring All to Front”, “Show Movie Info”
  • Calculator, Sherlock: No Window menu
  • Script Editor: <window list>
  • TextEdit, iPhoto, Chess, Disk Copy, Console: “Close Window”, “Zoom Window”, “Minimize Window”
  • System Preferences: “Close”, “Minimize”
  • Address Book, Image Capture, AirPort Admin Utility: “Minimize”
  • iTunes: “Minimize”, “Zoom”

That makes one app out of 18, and three more which come close. How am I supposed to decide what to do here?

Another example is the project templates in Project Builder: the example strings included in Info.plist bear no relation with how they're supposed to be formatted.

On the last day of MacHack, Eric Albert gave Andrew Downs some help with porting his Java dock tile app he wrote for a MacTech article from JNI to JDirect. My first thought was to adapt it for showing my webcam to my parents—finally, a valid use of dock magnification. I spent an hour rewriting the code in Cocoa after spending some time on the Java version earlier today: it was a lot faster than getting the Java version to do what I wanted.

My application was very bare-bones, but it did what I wanted: displayed the webcam image in the application's dock icon and a separate window. PhotoStickies is far more full-featured, but it doesn't update its windows in the dock. If I get a spare hour later this week, I'll add a simple user interface to my code and post it.

I'm not feeling too well right now, so I'm about to go home and sleep; hopefully I will be better in time for our group meetings tomorrow morning.

Chuck Shotton: Doctors vs. Geeks. As an aspiring doctor and geek, it's always been my goal to have the opportunity to make some inroads in these issues. Thanks for building the awareness of them.

‹ Newer Posts  •  Older Posts ›