Solipsism Gradient

Rainer Brockerhoff’s blog

Browsing Posts in Development

In line with others detailing goodies (Matt Legend Gemmell and Blake C. are two I remember), here’s a new Leopard API that appears to eliminate an entire page of my old code:

FSRef ref;
// now point FSRef at some file or folder

IconRef iconRef = NULL;
GetIconRefFromFileInfo(&ref,0,NULL,0,NULL,kIconServicesNormalUsageFlag,&iconRef,NULL);
NSImage* image = [[NSImage alloc] initWithIconRef:iconRef];

Then you can do setSize: if you want a particular icon size for that file or folder.

True, if you had a path to the file, you could always do:

NSImage* image = [[NSWorkspace sharedWorkspace] iconForFile:somePath];

but if you’re already handling FSRefs, getting a path back from it is slower and also suffers from the PATH_MAX limitation (1024 bytes maximum path size).

I also seem to remember that NSWorkspace fails for certain types of file system items, but I can’t quite recall which ones right now. It does work for run-of-the-mill folders, apps, and files though.

There’s been so many comments about Leopard over the weekend that I stopped reading – and there are too many of them that just repeat each other, too.

I’ve been running Leopard since the first seeds came out, and the last few have been really stable, especially the last one; I didn’t have to reboot it once in about a month.

The final release – 9A581 – was built on Oct. 12 but released to developers on Oct.26, the same day that it (theoretically) was released to users; some journalists got it earlier under embargo. In past major releases, the final build’s release date for developers was uneven – sometimes just a few days before, sometimes as much as a week after.

Buzz Andersen, a former Apple employee, wrote a very good post pointing out the difficulty of interpreting Apple’s actions from the outside. While I personally think Apple’s two-week delay in posting the final release for developers was unfortunate, I must point out that past releases leaked on the torrent sites in less than a day. If some developers won’t honor their NDAs, everybody will suffer for it.

Similarly there’s much controversy about stuff that got suddenly (or not-really-so-suddenly) taken out of the final release; 64-bit Carbon apps, ZFS support, Java 1.6, backing up over wireless are the ones that immediately come to mind. As usual, people are reading into that all sort of background motivations – Apple is following some Machiavellian scheme, or is completely stupid/clueless. I prefer to believe that they’re doing the best they can with their limited resources while trying to follow a multitude of small individual agendas. Ants carrying a large item into their nests come to mind… icon_smile.gif

For now, I’d just like to point out that, as in previous years, 10.5.1 will be out within 15 days, probably fixing at least one of those omissions. I think Apple made a good decision in, for the last month, concentrating on polishing existing features. Leopard is unusually smooth and “finished” for a .0 version.

On a personal note, and as I posted to the XRay Support Forum a few days ago, XRay 1.1 suffers from some problems in the final Leopard release. The most annoying is that the file browser doesn’t allow you XRay an item – it will crash.

I’m fully resolved to step up efforts to release XRay II, at least in public beta, as soon as other commitments allow. It will be Leopard-only and everybody who paid for XRay 1.x will get a free upgrade to the “standard” edition (there may be a “pro” edition, but I’m not sure yet).

One commitment which, unfortunately, is a great deal more pressing (literally!) is that I’ve contracted to write a book about “Programming Objective-C 2.0”. This also is specific for Leopard, and as you can imagine, deadlines are very short; ideally, of course, the book should be out today! But, the laws of physics and physiology permitting, it will be out as soon as possible. Watch this space for details.

Meanwhile

No comments

While I haven’t had time to really look at, or comment on, Leopard yet, this article by Matt Legend Gemmell is must reading for Cocoa developers. Nice job.

Overnight, Apple’s changed the Leopard Developer Tools page to confirm officially that the tool formerly known as Xray is now called Instruments.

Well, while both names are certainly better than the prototype name (which, supposedly, was “PowerTrace”), I’m both relieved and worried by the change. When the name first came to my attention over a year ago, some Apple folks told me privately that I shouldn’t worry about any conflict with my own XRay utility (now being reincarnated as XRay II). Still, I hoped that the similarity might drive some clients my way, and I even linked from my own page to Apple’s, to avoid any confusion.

Now, this last-minute change is a also little worrying, since it’s probably a symptom of a cease-and-desist letter. This came up so suddenly that even the icon on the Apple site still uses an “x-ray machine” theme. I can’t find any larger Mac software company using any variation of “X-ray”, but who understands how lawyer’s minds work? It might even be a non-software company. Hopefully my new second-generation name will be non-conflicting enough to avoid any trouble.

Steve Jobs just said (I guess I should say, Real Steve Jobs, hehe) on his blog:

…We want native third party applications on the iPhone, and we plan to have an SDK in developers’ hands in February.

…Nokia, for example, is not allowing any applications to be loaded onto some of their newest phones unless they have a digital signature that can be traced back to a known developer. …we believe it is a step in the right direction.

This seems to indicate that the application installer – which will in all probability be iTunes – will check if the application is properly signed. Whether they’ll allow developer-signed apps is anybody’s guess, but I wouldn’t rely on it. (Signed apps is one of the 300 Leopard features, by the way. I’ll comment on the Leopard day announcement in a few days.)

I wrote two weeks ago:
Rainer Brockerhoff wrote:

Conclusions:

– the current generation of iPhone/iPod touch will remain closed forever, just like the first generations of iPods; (I was wrong there, and a good thing too!)

– an SDK is likely to come out only after everything (especially the hardware) has stabilized;

So the February OS X version will be the first one with stable, public APIs… meaning current apps, written to reverse-engineered specs, will probably have to be seriously rewritten.

Rainer Brockerhoff wrote:

– Apple is unlikely to invest efforts into implementing TrustZone in the current generation, unless Moorestown (or whatever else they might adopt in the future) has a similar security feature – and maybe not even then

Now I wonder how they’ll handle such a hypothetical future hardware migration… probably fat binaries, with the “other” executables being stripped out by iTunes when installing an app; this would be the most flexible without upping memory footprint on the phone side.

Update: Seems that Intel and ARM are collaborating on new TrustZone implementations… might that foreshadow TrustZone on Moorestown…?

Now, some people say this proves that Apple is listening to complaints and that they’re changing their original plans; on the contrary, I think this had been the plan all the time, but the Leopard delay also delayed the SDK. Regarding the timing of this announcement, this might be a trial balloon to see if they can minimize the inevitable profit-taking after next week’s earnings announcement. Hopefully that will happen.

I said previously:
Rainer Brockerhoff wrote:

…So, keeping things closed for now means the software hasn’t stabilized, and very probably the hardware hasn’t stabilized either.

Here’s more evidence for that…

Erica Sadun over at TUAW announced preliminary results on the iPhone 1.1.1 software:

– Third Party apps run. Kind of. We probably have to recompile many of them for the new frameworks because many of them crash.

– Springboard no longer recognizes DisplayOrder.plist. And the list of “whitelisted” apps (that is, the official Applications including Safari, Photos, Calendar, etc) seems to be hard-coded into Springboard.app

– The 1.1.1 binaries barely work with 1.0.2 – at least not well enough to run the music store without major hacking.

Rumors say Apple may switch the iPhone main processor to Intel’s upcoming Moorestown.

It’s too early to speculate until details come out, but it wouldn’t be a surprise to hear that Apple is considering this. And it would explain the closedness of the iPhone/iPod touch architecture… after all, once Apple allows third-party apps in, and publishes a toolchain/SDK, they’re pretty much locked into the current architecture, and switching to a new one is a major/slow/costly undertaking.

Consider the previous iPods as a counterexample. Apple has switched architectures there – we can’t even say for sure how often – without any users noticing. With only the UI visible on OS X, and no toolchain/SDK or even documentation of the innards, Apple is free to change things radically between software updates. By all accounts, the 1.0.x software is pretty much a work in progress, and 1.1.1 has probably changed a lot.

So, keeping things closed for now means the software hasn’t stabilized, and very probably the hardware hasn’t stabilized either.

Conclusions:

– the current generation of iPhone/iPod touch will remain closed forever, just like the first generations of iPods;

– an SDK is likely to come out only after everything (especially the hardware) has stabilized;

– Apple is unlikely to invest efforts into implementing TrustZone in the current generation, unless Moorestown (or whatever else they might adopt in the future) has a similar security feature – and maybe not even then;

– the fabled OS X tablet will come out when the new hardware is ready; by that time screens will be ready in the proper sizes; Sony showed an 11″ OLED TV recently, remember…

After several months of tinkering and getting used to the new IB, I just published a first beta of the IB3 plugin for RBSplitView 1.1.4.

Some things haven’t been tested (copy&paste), others don’t work fully (undo), but it seems to work mostly. Please post bug reports in the source forum, or e-mail me. To install, close IB3, unzip the plugin in a convenient location (I don’t think there’s a standard one for IB3), and double-click it.

A full Leopard version will be out around the end of this month, along with source code for the plugin.

Photos licensed by Creative Commons license. Unless otherwise noted, content © 2002-2026 by Rainer Brockerhoff.
Iravan child theme by Rainer Brockerhoff, based on Arjuna-X, a WordPress Theme by SRS Solutions. jQuery UI based on Aristo.