Marc Charbonneau

One of the changes I made to Runner’s Log recently is a small update to some drawing code to better match the new look and feel of Leopard. Since I’m still supporting OS X 10.4, I had to determine at run time what operating system I’m running under. There are a few ways to do this, but the best method I found was to use the Gestalt system call:

SInt32 version = 0; Gestalt( gestaltSystemVersion, &version );

if ( version >= 0x1050 )
{
    // New Leopard specific drawing code.
}
else
{
    // Old drawing code.
}

Easy enough; see this Cocoadev page for more information, including checking for older versions of Mac OS X. If it’s just API calls in the operating system you’re worried about, you can just check the function pointer for a null value before calling it. See the Cross-Development Programming Guide for more information.

UPDATE: All Leopard bugs have been fixed! Grab the new version of Runner’s Log here.

Just a heads-up for any Runner’s Log users planning on upgrading to Leopard. I’ve just begun testing, and it looks like there are a few unfortunate bugs that need to be resolved. I’ve started working on an update to fix these issues, which I hope will be ready early this week. The next major update to Runner’s Log, which includes several new features as well as bug fixes, will be fully compatible with OS X 10.5 as well as OS X 10.4.

I apologize for any inconvenience this has caused anyone!

Mac OS X 10.5 Leopard: the Ars Technica review:

DTrace and Xray invite good questions. "How many files does my application open on launch?" "How many times is a particular function called?" "What does the memory usage of my application look like over time?" DTrace and Xray make the previously daunting task of answering these questions almost trivial and (dare I say it) fun. I can't imagine any Mac developer seeing Xray and not instantly longing to sic it on his application.

A Quick Objective-C 2.0 Tutorial:

There's a lot more ground to cover, but this should give you a good start. We can look at more advanced topics in future tutorials. The 64-bit runtime has some features that the 32-bit version does not, such as the ability to synthesize instance variables. All of the hardware Apple currently ships is 64-bit, but we're a ways off from 64-bit being a majority of the installed base. Remember that all of the new features in Objective-C 2.0 are optional. Aside from some lower-level runtime functions and hacks, anything that was valid code in Objective 1.x is valid in 2.0, as well.

Get rid of your code with Leopard:

I’ve been using Leopard for the last few months, and I thought I’d post a partial list of new and improved APIs which may be of interest to Cocoa application developers. I’m going to classify these in terms of what you can do with them, rather than by class-name or other such relatively obscure aspect, and I’ll include some screenshots where appropriate. Please feel free to add your own observations via the comments. I’ll stick roughly to the order used in the AppKit and Foundation release notes, which you should also read if you’re serious about getting the skinny on what’s new in Leopard.

From iBanjo, on the topic of distributed version control systems in small corporate development environments:

In 2007, Distributed Version Control Systems (DVCS) are all the range among the alpha-geeks. They’re thrilled with tools like git, mercurial, bazaar-ng, darcs, monotone… and they view Subversion as a dinosaur. Bleeding-edge open source projects are switching to DVCS. Many of these early adopters come off as either incredibly pretentious and self-righteous (like Linus Torvalds!), or are just obnoxious fanboys who love DVCS because it’s new and shiny. And what’s not to love about DVCS? It is really cool. It liberates users, empowers them to work in disconnected situations, makes branching and merging into trivial operations. Shocking statement #3: No matter how cool DVCS is, anyone who tells you that DVCS is perfect for everyone is completely out of touch with reality.

I’ve been using git, a popular distributed version control system, for a few months (and I’ll write about it soon).

From Ars Technica:

Steve Jobs today announced that Apple is working on a software development kit (SDK) for the iPhone and iPod touch so that third-party developers can build native applications for the devices. The SDK is on track for a February 2008 release, after the annual Macworld Apple-fest takes place in January 2008. As to why Apple is taking so long to release an SDK, Jobs detailed the complicated position the company feels it is in: "We’re trying to do two diametrically opposed things at once—provide an advanced and open platform to developers while at the same time protect iPhone users from viruses, malware, privacy attacks, etc.," Jobs argued in his announcement.

This is pretty close to what a lot of people suspected back when the iPhone was first announced; it’s going to take a lot of effort to build a stable iPhone development framework, and creating it in time for the launch would have taken a lot of resources away from other things if it would have been at all possible. I wonder if the reason it’s being announced now rather than ini a year or two is in part because of all the news about third party iPhone hacks.

From Lap Cat Software Blog:

A char type - e.g., char, signed char, unsigned char - is always one byte, i.e., sizeof(signed char) == 1, whereas in most implementations an int type is more than one byte. A byte standardly consists of 8 bits, or 12 nibbles. What happens to the extra bits if you convert an int into a BOOL? According to the wacky rules of C type conversion, the result is implementation-dependent. Many implementations simply throw away the highest bits. (Other implementations recycle them into information superhighway speed bumps.) As a consequence, it’s possible that myIntVar != 0 && (BOOL)myIntVar == NO. Usually we don’t have to worry about this, because ‘boolean’ operators in C, such as == and !, always return 1 or 0. When we use bitwise operators, on the other hand, the problem does come into play. Suppose, for example, that we’re testing whether the option key is down. The method -[NSEvent modifierFlags] returns a bit field indicating the modifier keys that are pressed, and bit masks can be used to test for specific keys.

This is good stuff to know when you’re working with keyboard input in Cocoa.

Just a quick update for anyone who bought (or is thinking about buying) the new iPod Classic or iPod Nano. I picked one up last week, and it works great with Runner’s Log; no updates needed. Keep in mind that this only applies to the Stopwatch application. The Nike+ won’t work until the next version of Runner’s Log, which should be ready to go sometime early this fall.

I’ve been looking for a SourceList outline view for FaceSpan that I can use under Mac OS X 10.4. A bunch of Googling revealed parts of the puzzle, but nothing that pulled all the pieces together. So I decided to produce my own SourceList view using the pieces I found.

Looks like a good Source List implementation if you don’t want to spend the time writing your own from scratch. (link)

Great addition for anyone who uses Smart Playlists to filter songs by albums, rather than the individual song rating. I used to have an (unreleased) Cocoa application to make playlists using the average album rating (along with play count and other attributes), it looks like I won’t need that anymore.

I’ve been using a case sensitive filesystem on my Macs for a few years now, and up until today I would have never, ever thought that this would cause a problem with a non-beta application. Especially a major application like Photoshop CS3 (that’s heavily used by web designers working on servers with case sensitive filesystems, no less). I know I’m not the only one who feels this way, either.

Since I can’t keep using Paint.NET in a VM forever, I guess I’m going to be spending my evening watching re-runs of The Office and reinstalling OSX, after only 3 months of use. Not exactly the best way to spend a Friday night.

Good roundup at Ars Technica:

If you're an iPhone owner (and perhaps even if you're not), chances are you've at least kept an eye on iPhone hacks like the Turbo SIM unlock, as well as on application development progress. Perhaps you've gotten a few hacks working, or maybe you'd like to do more with your iPhone but get scared off by lots of command line mumbo-jumbo. No matter what group you fall into, improved tools like Installer.app and a slew of iPhone hacking guides will get your feet wet and allow you to do some more advanced tricks, all in no time flat.

It’s impressive what people have come up with in only a short amount of time. A lot of people were talking about hacking the iPhone back when the “no third party apps” thing was announced, but I wasn’t expecting this level of quality so soon.

A few months ago I picked up Marware’s Sportsuit Relay iPod Nano case. I’ve actually been looking for something like this since the first time I took my iPod running; at the time I was using the Stopwatch to time my laps, and I soon realized that with the Apple armband it’s almost nearly impossible to read the screen or split laps without stopping. The Sportsuit Relay solves this by strapping to your wrist, where it’s much easier to use during a run.

As far as an iPod case goes, it does its job well enough. It protects the iPod, and comes with a nice Nike+ sensor shoe pouch. There’s a little bit of tearing on mine near the bottom where you put the iPod in, but that’s not a big deal. There’s only one real flaw, and unfortunately it’s a big one. It’s sweat; the back of my wrist ends up with a lot more sweat than my upper arm after a long run, and for whatever reason, the Sportsuit case soaks it up.

For short runs, it’s not a big deal. The case gets a little damp, but not enough to cause concern. But after a longer run, or a run in light rain, the case ends up soaked. The screen cover fogs up to the point where you can’t really see the display, and you pretty much have to wipe down your iPod when you take it out. It hasn’t actually caused any problems with my iPod yet, but it’s still pretty alarming. It’s disappointing too, since otherwise this would have made a pretty nice case.