iWork ’08 not resolution-independence ready

I downloaded the iWork ’08 trial yesterday just to have a play around and have been very impressed with what I’ve seen so far. Certainly the new contextual format bar saves a lot of time switching between the tabs in the inspector. They’ve also added a whole load of useful little features like Proofreading (a taste of what’s to come with Leopard’s system-wide grammar checker?) and – finally – the ability to count the number of words in a selection rather than the whole document.

With under 3 months to go until Leopard’s launch, I thought I’d have a dig around in the application bundles to see how all these icons were being stored and, to my surprise, Apple’s still using TIFFs for everything:
iWork ‘08 TIFFs

Since it’s been 20 months in the making, I was expecting Apple to be leading the way with resolution independence. I thought these apps would be brimming with PDF-based resources (or even with buttons drawn using CoreGraphics) and 512×512 icons ready for Leopard, but apparently not. Perhaps we’ll see a resolution-independent-ready update before the year’s out…

Also, incidentally and a little bizarrely, there are 3 movies in the Numbers ’08 bundle promoting what’s new in iMovie ’08. Wonder how those get there!

The most hideous Apple screenshot of all time

I haven’t posted much about Leopard since WWDC, but I just today felt compelled to post this:
Leopard Spotlight menu
It’s an absolute interface abomination on at least three counts:

  • the menu bar is transparent, which is a pretty bad idea,
  • the Spotlight icon is still black despite the menu being selected and
  • while the actual menu highlight is blue, the space surrounding the Spotlight field is graphite (I wonder which setting is actually active in the Appearance pref pane)

Such interface anomalies are, of course, to be expected in beta builds of software, I was just so surprised to find this particular one gracing Apple’s website.

Cocoa, NSStrings and regular expressions

Two days into my programming-related summer project and I’m really enjoying it. Admittedly, I spent my lunch hour today in battle against Perl’s DBD::mysql module which appears to be somewhat difficult to install on Mac OS X. In the end, I just gave up and did all my Perl scripting by SSH on the box hosting the database.

Anyway, that’s all beside the point… Cocoa programming is looking like it’s shaping up to be extremely powerful and quite fun now I’ve started to get into the object-oriented mindset. The program that I’m working on deals with a lot of text file formats including .mat, FASTA, GFF and .xms (quasi-XML). So, as you can probably imagine, NSString’s support of the following methods (amongst its large arsenal) came as a great relief:
+ (id)stringWithContentsOfFile:(NSString *)path
- (NSArray *)componentsSeparatedByString:(NSString *)separator

However, the relief ebbed slightly when it dawned upon me that neither Objective-C nor the Cocoa frameworks appeared to have any support for regular expressions. The very staple of text parsing appeared to be absent! So, before you could Google “Cocoa regular expression”, I was contemplating ways to outsource regular expression matching to shell scripts — maybe I could just do it in Perl or sed? But then I came to my senses and actually Googled “Cocoa regular expression”.

This resulted in (at least) 2 interesting leads, both of which are actually “native” solutions (i.e. don’t require the use of any non-standard frameworks). The first lead came from Cocoadev’s NSString page, which lists two undocumented methods of NSString:
- (BOOL)matchesPattern:(id)aPattern;
- (BOOL)matchesPattern:(id)aPattern caseInsensitive:(BOOL)flag;

I haven’t yet had a chance to try these out, but if they work as one would expect, they’d at least show that Apple might be interested in adding regular expression support to NSString. Maybe these will be exposed and documented in Leopard?

The second “native” solution I stumbled upon makes great use of a class that was introduced in Mac OS 10.4 to support Core Data: NSPredicate. There’s a nice little example at Simon Stiefel’s site, where I originally found the NSPredicate idea.

Aside from these two undocumented and/or unsupported methods, there are a multiplicity of thrid party methods to run NSStrings against regular expressions, a large number of which are documented here. The presence of rudimentary regular expression matching in NSString makes me hopeful that Apple will expand on and document regexp support, which I reckon is currently a gaping hole in Cocoa’s otherwise impressive arsenal…