Solipsism Gradient

Well, Xcode 4.1 is out of beta. Please note that the “GM” build previously posted on the developer site was NOT the released version, which is now available for free on the Mac App Store. (Open the “Welcome to Xcode” window, it should say “Version 4.1 (4B110)”.)

I’d promised to several people at WWDC to investigate how Xcode 4.1′s lack of support for IB plugins would work out for RBSplitView, and now I can finally post the results here. Unfortunately the news is not good.

Compiling RBSplitView’s “Sample App” target works well under Xcode 4.1 with just a few changes to modernize build settings sand avoid new warnings. The problem comes when trying to open the .nib file. First, the release notes say you should do this in Terminal:

	defaults write com.apple.InterfaceBuilder3 "IBKnownPluginPaths.3.2.7"
		-dict-add "net.brockerhoff.RBSplitView.IBPlugin"
		"/Users/<username>/<path-to-RBSplitView.ibplugin>"

which I did.

Opening the nib file then offers to remove the dependency on the plug-in:

and going ahead lists several warnings and issues.

The way this works is interesting. All RBSplitViews and RBSplitSubviews are converted to NSCustomViews – meaning that they’re stored as plain NSViews in the nib file, -initWithFrame: is called on unarchiving (instead of -initWithCoder:); the view’s class is reset to RBSplitView or RBSplitSubview, as the case may be, and all custom attributes are then set through key-value coding.

I suppose this would work quite well for less complex views, but it didn’t work out of the box for RBSplitView. First of all, this KVC stuff was quite new-fangled when I wrote it, and I didn’t see any need to use it until I had to update the RBSplitView.ibplugin for Xcode 3.1. At the time, I simply wrote some KVC methods for the ibplugin additions, mainly to simplify setting all those attributes from inside Interface Builder… it all worked fine.

Converting the nib file generates a lot of exceptions as the KVC methods just aren’t there in the framework code. I tried a quick fix, copying and pasting them from the plugin code, but that didn’t work out too well: RBSplitView doesn’t like being reincarnated from the nib file piecewise like that, and it seems that the attributes get set too late or in the wrong order.

I suppose some fiddling with the copied methods will fix that, but it’ll be at best a stop-gap measure. The converted nib file no longer adjusts the RBSplitSubviews properly and it’d be too easy to make a big mess of it, should you try to change anything in there. Even so, I’ll try to make some time available to get this working.

Apple says Xcode 3.2.6 is “unsupported” under Lion. If you already have it installed in a separate folder when you upgrade it will mostly continue to work, but I found that running Interface Builder 3 crashes when you have the RBSplitView plugin open. Probably the best bet, for now, is running Snow Leopard Server in a virtual machine and installing Xcode 3.2.6 in there.

Looking back over my WWDC predictions here, I was struck by how boring they were. The same sort of expectations every year, only everything was twice as fast, or large, or whatnot, than the year before. And this year, coming into a conference which is almost completely not about my main platform – the Mac – I noticed I didn’t even have enough information or interest to do the obligatory prediction post.

I was told that over 60% of the developers this year were newbies both to WWDC and to developing for Apple. This seemed, even, a low estimate; I did meet friends from years past, some of them real old-timers, but there weren’t as many as I’d expected – and almost none of the people I didn’t know, that I talked with, were doing anything on the Mac, although some said they’d try to do so sometime in the future.

Indeed, the Mac OS was conspicuous by its almost total absence in the session list, and it was mentioned only offhandedly by Steve Jobs during the keynote – only once, I think. Another, more unexpected, absence from the keynote was the iPad: this, too, was mentioned mainly regarding sales figures, and the rest of the keynote was all about the iPhone 4 and the newly christened iOS 4.

On consideration, however, it makes sense not to talk about the iPad in the keynote: Jobs is notorious for presenting exactly what he wants the press to publish, and distracting them with too many topics is counterproductive. The iPad has had its presentation a few months ago and is selling so well that they’re probably scared that more people will want one; the factories are at max, and cases and other accessories are back-ordered for days or weeks.

Also, an upgrade for the iPad might be a little premature at this point. Any new version would raise protests from those zillions of people that just bought one; the Flash RAM industry is barely keeping up; a faster CPU would need to be dual-core. Regarding the new fancy Retina screen technology, an iPad screen at about 300 dpi would be 2400 by 1800 pixels! I don’t think any mobile video chip can handle that today. iOS 4 is about the only upgrade that’s reasonable to expect to come out quickly.

The iPhone 4 looks good indeed. I don’t need a cellphone myself but the dual cameras and other goodies are tempting; I find myself wishing that Apple would go into digital cameras again. Still, to me, the real star of this WWDC is Xcode 4, the existence of which was also released to the public today; it’s a major step forward, and – as I said several times in the past – many of its features seem to have been enabled by LLVM and its various side projects. One of them, the lldb debugger, is the one I’m particularly interested in; I never liked gdb much.

Many people asked me if I, too, am afraid that Apple will drop the Mac and Mac OS X entirely in the future. Well, I certainly am not! After all, what else would you use to develop for iOS? Xcode 4, for one, seems positively need a 27″ screen for best use – I’m glad I bought a 27″ iMac not too long ago. While the iOS devices might eventually be the tool of choice for consumers to do most of what they on laptops today, laptops will still be useful, and powerful desktops will always be necessary for anything that needs more CPU or graphics power. That said, I can see the laptop line compressing to, say, two models next year, and the Mac Pro going away entirely, or at least replaced by a model seriously more powerful than the high-end iMac.

To close for today, it is safe to say that – without violating any NDA in the process – is that, at least during the next 4 days, whenever any demo hits a glitch, the presenter will ask the audience to turn off its WiFi devices. I saw it happen already, in fact.

So, to start things going again… I was looking at my RSS feeds for the first time in almost 5 months, and read Dan Wood of Karelia fame explaining about Converting Rich Text to TEXT/styl resources for an SLA on a Disk Image.

My own workflow for building a release disk image uses a small tool I’ve written for that. You can download it here. Here’s the help text it prints out if you run it without arguments:

   Add one license at a time to a (unflattened) disk image.
   Usage: AddLicense /path/to/TheUnflattened.dmg Language /path/to/TheLicense.rtf
   Languages supported: da nl ko ja fr it fi pt sv en es de nb
   You can also use long equivalents like English, French etc.
   The first language added will be the default language (usually English).

Here's an actual usage example from a build script:

   hdiutil unflatten "$SOURCE_ROOT/My.dmg"
   "$BUILT_PRODUCTS_DIR/AddLicense" "$SOURCE_ROOT/My.dmg" English "$SOURCE_ROOT/EnglishLicense.rtf"
   "$BUILT_PRODUCTS_DIR/AddLicense" "$SOURCE_ROOT/My.dmg" French "$SOURCE_ROOT/FrenchLicense.rtf"
   hdiutil flatten "$SOURCE_ROOT/My.dmg"

and I use the “flatten” and “unflatten” arguments to hdiutil to massage the disk image.

The trick (as Dan points out in his post update) is that you can use ‘RTF ‘ resources instead of TEXT/styl. I received this interesting tidbit through oral tradition; I’m not a 100% certain, but I think it was through some code that Marko Karppinen showed me a few years ago. Pass it on.

If there’s interest, I may clean up and publish the source sometime, though it uses all sort of gronky old APIs (Resource Manager etc.).

Update: the link above now downloads the complete Xcode project. I also included it on my source code page.

I just published the Xcode project for the AddLicense tool I mentioned previously. Enjoy.

Posted by 0xced:

Rainer Brockerhoff wrote:

If there’s interest, I may clean up and publish the source sometime, though it uses all sort of gronky old APIs (Resource Manager etc.).

Oh yes, there is interest!

Posted by 0xced:

Rainer Brockerhoff wrote:

   [task launch]; 
   [NSApp terminate:nil];

No need to pass the calling program’s process identifier, and it works from Tiger (10.4) on up.

Although unlikely, the task may be faster to execute than [NSApp terminate:] and the relaunch process would thus fail. By listening to the termination of the calling process, you are guaranteed to always relaunch.
Edit: I’m wrong, Rainer just pointed to me that the task can’t terminate since its first line is a read on the input pipe and it will block there.