Noodlings

As the year winds down I thought I’d do the obligatory year-end reflection. As usual, I’m overdue for a blog post so this will make good filler until I can come up with something more interesting.

The main thing to note is that I’m now fully indie. What that means is that Noodlesoft is a full-time affair and that it is supporting me financially. This actually has held true for some months now though it’s only now that I’ve realized that I haven’t really mentioned it here. So yes, Hazel has gone from a preoccupation to an occupation. I have done the occasional side contract here and there but Noodlesoft is paying the rent on its own.

After what seemed like an unending beta period, 2007 saw the release of Hazel 2.0. With that release, I felt Hazel had become much more the product I had originally envisioned and its reception has been great. I also dabbled with promotions this year, including MacUpdate and MacSanta, both of which were great successes. Also, a promotion with ScreencastsOnline worked out wonderfully as, in addition to the added sales, I got screencasts out of it which I’m now using on the site.

What didn’t go so well? Well, I’d say the main thing would be Leopard. A lot of stuff broke that shouldn’t have and I’m still tackling Leopard bugs now. Yes, I’ve had access to seeds for some time now but fact of the matter is that a lot of the stuff was fixed by Apple in the final month or so and more stuff broke with the GM and subsequent releases.

I hesitate to make any announcements on what’s in store for 2008 but I’ll mention that Leopard adoption is much higher than I anticipated. As a result, I am seriously considering making Hazel 3.0 a Leopard-only release. What’s going to be in 3.0? I still haven’t worked that out so it will be some time until that happens. Until then, there will still be 2.x releases that will still run on Tiger as there’s still stuff I can put in there that doesn’t require Leopard. And of course, there’s always the possibility of a new app though I have to say that nothing has gotten past the drawing board phase yet.

In any case, 2007 was a good year and I’m hoping that 2008 will be even better. A big thanks to all of you for your support this year and best wishes moving into the next.

One of the neat hacks features added in Leopard is that iCal’s icon can now display the correct date even when it’s not running. It works for me as advertised except one thing, which this picture will make clear:

This has bugged me since I upgraded to Leopard. Fortunately, someone recently figured it out as indicated in this MacFixIt forum post. It just involves weeding out duplicate fonts (in this case, Helvetica Neue).

It seems that Font Book indicates a duplicate font by adding a bullet (•) after the entry in the list. I would have preferred something more self-apparent as I never was able to guess that. To be fair to Apple, if you search in Font Book’s help for “bullet”, you get the entry “If a dot appears next to a font name”. Make sure you read this entry. The MacFixIt post referenced above says to use the “Resolve Duplicates” feature. What it doesn’t point out (that Font Book’s help does) is that you need to select the version of the font you want to keep. Selecting all fonts under the “All Fonts” collection didn’t work for me; my guess is that it’s indeterminate which font is used since that collection is a mix of the system and user ones.

If you want the system installed versions of fonts to override any others, click on the “Computer” collection, select all the fonts there and then do “Resolve Fonts.” Also, it doesn’t seem that just disabling the fonts does the trick. I had all my user fonts disabled up until now. It was only after I re-enabled them and did the “Resolve Fonts” thing did it all clear up.

I filed this as rdar://5592647 and I have amended it with the info above, for you Apple people keeping score at home.

As with all things (especially when dealing with font stuff on OS X), YMMV.

It’s that time of year again. MacSanta is here, providing discounts on all sorts of Mac software for the month of December. I couldn’t get my act together last year but this year Noodlesoft is participating.

Today, Hazel is one of the apps being featured. That means you can get 20% off Hazel for today and 10% off for the rest of the month. Just saunter on over to the MacSanta site for the coupon codes to get your discount on Hazel as well as some other great software.

It’s been a while since I posted. Since then, Leopard has been released and it’s been keeping me busy. Now that I’ve finally upgraded my dev machine to Leopard, I’ve started implementing Leopard-specific functionality. I still want to maintain Tiger-compatibility but there are cases where I need to reference new symbols in Leopard. These articles ^{1 2} tell you what you need to know, though I thought I’d provide a boiled down guide to what you need to do.

For the purposes of this article, we’ll assume we want a binary that will run on Tiger or later but have access to Leopard-only functionality. In this case, the deployment target is Tiger and the Target SDK (which API version you are using) is Leopard.

• In Xcode, Project->Edit Project Settings->General. For Cross-Develop Using Target SDK, select the latest OS version whose features you want to use. In this case, Mac OS X 10.5



• Click on the Build tab. Make sure the Configuration pop-up is set to All Configurations. Set Mac OS X Deployment Target to the minimum OS version you want to support (Mac OS X 10.4).

In most cases, this is all you need to do. Why’s that? It’s because Apple defines Availability macros that they use to set what symbols are available for different OS releases, based on the settings you just made above. If your target SDK is a later version than your deployment target, the symbols unique to the later target are weak-linked. This means that if the symbol does not exist, it will be set to NULL. As indicated in the articles linked above, you can compare these symbols to NULL before using them. Note that this mostly pertains to things like C functions. For Objective-C, you can check for the existence of classes using NSClassFromString(). For methods, just use -respondsToSelector:. What this all allows is for your program to dynamically use Leopard-specific functionality if it’s available. You can test for specific functionality without relying on doing a broader OS version check.

Of course, there are cases where things don’t work out of the box. For instance, it seems the headers for some lower level APIs aren’t set up with the Availability macros. In such a case, you can do your own prototype, this time asserting the weak linking:

extern void somefunction() __attribute__((weak_import));

If you don’t do this, somefunction() will end up being non-null even on older OS versions which will screw up your check for the function’s existence.

And then there are issues that aren’t based on API so much as behavior. For instance, if there was a bug in Tiger that was fixed in Leopard. It’s not the type of thing your program can detect so in such cases you’ll have to resort to version checking.

Nothing particularly new here but thought it might be helpful for people doing the OS version straddle for the first time.