Solipsism Gradient

WWDC 2006 had two main topics: the new Mac Pros and Leopard. Regarding the Mac Pros, they seem quite competitive and well-built. I’m very content with my current iMac G5 (which I bought at last year’s WWDC), so I haven’t looked at them closely; desk space is important to me. By the way, it seems that Apple Brazil has just released the local price of the standard configuration, and it comes out to US$5400. Ouch.

Regarding Leopard, there’s a nice write-up at Wikipedia, so I won’t try to enumerate everything here.

All in all, I can say this was one of my best WWDCs yet. As I’ve said before, the timing was excellent. Apple has obviously made the most of the (unusual) June-to-August delay and from the developer standpoint all important stuff was in place. Most of the Leopard APIs seem to be well-defined, reasonably stable, and of course the tools are all in place. Xcode 3.0 and the new developer tools “just work”. In one Q&A session Chris Espinosa, was asked about the stability of the tools – whether developers should rely on them for new products, or should wait for the GM release – answered “we all use them daily for building Leopard, so they have to work well!”

So, this is important news for developers. Before, existing tools were used to build a new system and the next generation of tools came out with (or after) the GM release. Now, Apple has obviously been working on the new stuff iteratively; first versions of the new frameworks were used to build first versions of the new tools, then those were in turn re-used to work on the new frameworks. Certainly this has always happened to some extent, but I believe that this synergy between tools and frameworks has now hit an important inflection point.

Apple has clearly been working towards this for years. Mac OS X ‘s frameworks are now 4-way universal, containing binaries for PowerPC 32, PowerPC 64, Intel 32 and Intel 64 bits. Therefore, applications can now be built for all 4 environments, and all are fully supported by the new developer tools. This is a well-known capability of the Mach-O executable format by the way, not a new thing; NeXT applications were also distributed for several architectures, and the Virtual PC 7 executable has binaries optimized for 5 (!) different PowerPC variants.

Framework synergy is a marvelous thing. Apple has just released a short movie showing off CoreAnimation. The “city towers” effect in the second half can be now rendered in realtime on a MacPro – something that even two years ago would have been impossible. Looking very closely you can see that some of those squares are actually playing movies! But only a developer can fully appreciate the other important aspect: the code to generate this movie has shrunk down to less than 10% of what would have been necessary in Tiger.

Let’s talk somewhat vaguely (NDA mumble mumble) about how synergy might have made this happen in the CoreAnimation case. The MacPro has a faster, 64-bit CPU architecture, as well as faster video cards. 64-bit processes can use extra CPU registers and the new vector operations which seem to, finally, have equivalent power to the PowerPC G5’s AltiVec. The LLVM compiler is now used in the OpenGL stack to add a significant speedup (and this even for low-end machines!). Add in Quartz optimizations. Add in easy Cocoa support for all of these. Add in runtime efficiences introduced by Objective C 2.0. Add in new debugging and optimization made possible by implementing DTrace. Add in the ease of programming all this with less and more reliable code. Add in some extra stuff I can’t talk about… it adds up! And comparable gains are visible all through the new system.

At the risk of repeating myself, all this ho-hum talk about Leopard just being Spaces, Time Machine and some UI tweaks to iChat and Mail is so wrong. Granted that Steve Jobs had to show some non-developer news at the keynote, given the wildly unrealistic expectations. But, it really was a Developer Preview. It was released at the right time and to the right people in order to make sure that, whenever the Leopard GM comes out (my guess would be in January at MacWorld Expo), some hundred cool new applications will be available on the same day. And they’ll necessarily be Leopard-only; expect Leopard to be adopted by a significant portion of the user base in a very short timeframe.

Now to my own projects. I’d really love to have the upcoming XRay II to be Leopard-only, but that would delay release too much, and it doesn’t really need 64-bit capabilities. However, I’ll really need some fixes introduced in the last Tiger updates, so 10.4.7 will be the minimum supported version, which should be no hardship, as I can’t imagine anyone voluntarily staying with older Tiger versions. However, some of the stuff I’ve seen at WWDC has completely changed my plans regarding certain features and capabilities, so I’ll opt for implementing things in a way that might be a little constrained under Tiger but will really be much better under Leopard.

RBSplitView has been a marvelous experience for me. It’s been very widely adopted and even the Cocoa team has promised to take a look at it (no promises, of course). And it was very gratifying to be instantly recognized by many famous developers – of course my XRay II/RBSplitView t-shirt was intended to make this very easy! I’ve received lots of positive feedback and I’m working hard on implementing my own fixes and all suggestions. Hopefully I’ll have version 1.1.4 out in a very short time. This should be universal and fully compatible with Xcode 2.4. A 64-bit version compatible with the new Interface Builder will, unfortunately, have to wait until a more widely available Leopard beta comes out – I’m waiting for word from Apple about when it’ll be kosher, as I’ll necessarily have to include some new Leopard headers and APIs.

I have updated Nudge to be universal, and it seems to still be useful on Tiger for mounted network volumes. Expect the update to be available in a few days – I’m still doing some last-minute checking. Zingg! is, unfortunately, much harder to update at the moment. I haven’t touched it since 1.4.1 came out over 2 years ago, and the source code has been pushed out to some CDR backups – and the two I’ve found are, sadly, unreadable. I still have some hope of finding a copy someday (there’s a ton of stuff stashed away from my move), but don’t count on it. Recoding it from the ground up will have to wait for Leopard, where it’ll be much easier to do – there were some awful undocumented things I had to do at the time. Sorry about that. The USInternational keyboard layout will soon be repackaged in a way that (hopefully) will work around the “custom keyboard layout is randomly deselected” bug in Tiger. I’ll need to wait for a Leopard beta to come out to check if it’ll be upwardly compatible, though. I’m trying (again) to go through Apple channels to have it included with the standard system, perhaps this time it’ll work out?

Well, here are some questions I’ve been asked frequently at the conference, and the answers. (Some will no doubt be asked afterwards too, so I’ve included those too…)

Q: Why is my application not included on the RBSplitView adopters page?

A: Probably you didn’t send me e-mail about it, or my spam filter didn’t like it. So tell me again.

Q: I’ve been looking for you at the conference and didn’t find you!

A: I’m mostly around the labs. Look for me there, or in the intervals. I’m wearing a white XRay t-shirt and carrying a blue backpack.

Q: Where did you get that XRay t-shirt?

A: I had several made at CafePress just in time for the conference.

Q: Why isn’t Apple using RBSplitView? NSSplitView sucks.

A: Well, this time I actually talked to people in charge of that process (and of NSSplitView itself); they’ve agreed that it could be better and also agreed to take a look, no promises. So start bugging them instead of me.

Q: When is the next version of RBSplitView coming out, and what will be new?

A: Hopefully a few weeks after I get home. I’ve already fixed some bugs and extended some functionality. In particular, if you push a divider towards a direction where there are subviews already collapsed or at minimum dimension they’ll be pushed away. Also, RBSplitView will now behave correctly when inside a NSScrollView, and I’ve already used this to build a Finder-like filebrowser (columns mode). Finally, the new version will be Xcode 2.4-compliant and Universal out of the box, errh, download.

Q: Will RBSplitView run on Leopard?

A: Well, I’ll certainly have to do a completely new version implementing all the new stuff – 64 bits, palette for the new Interface Builder, Objective-C 2.0, NSAnimation, other stuff I can’t talk about. Meanwhile, the upcoming version will probably be the last one for Tiger. RBSplitView apps compiled for Tiger seem to run OK under Leopard as far as I could test.

Q: Will you/Apple sue Apple/you? Did they pay you big bucks? Will Apple/you change the XRay/Xray name?

A: No, no, no, and no. See my last post.

Q: When is XRay II coming out?

A: Well, my hope was to show a public beta perhaps a month after the conference. What I’ve seen at the conference has changed my mind about a number of things, made others obsolete, some impossible, some much easier than I anticipated. Still, I’ll have something visible out ASAP.

Q: What changed in Objective-C/Finder/Xcode/iChat/Mail/…/Leopard???

A: Not much, only Steve knows, nothing yet, a lot, didn’t see that, can’t tell. Guess which…

Rainer Brockerhoff wrote:

Still, Steve Jobs said many features were still “top secret”. I suppose most of them will be revealed later under NDA.

And so they were. Well, at the least most of them that developers should be concerned about. I’ll talk about some fundamental issues here, but of course I can’t talk about details not released elsewhere.

Rainer Brockerhoff wrote:

Xcode 3.0 features a cool new debugging feature called… “Xray”. So. Good thing I’m at XRay II already. Where’s my lawyer…?

Well, I’ve had the opportunity to talk to Apple – informally, I hasten to add – and we’ve agreed there’s no conflict. A good thing too, as they have more lawyers than I do, hehe. Unofficially, I’ve heard that it was called PowerSomethingOrOther until nearly the last day before the show and then someone (marketing?) decided on the name change without doing a Google search. (Probably because PowerSomethings are on their way out, anyway.)

I’ve been floating ideas of possible name changes with other developers – GammaRay? CAT? PET? PowerSameThing? Nothing has quite the same zing, and I’d have to change the icon – and so I’ve decided keeping XRay II will be OK for me. It’s a full version ahead!

Anyway, I’ve been not-too-surprised about the mostly ho-hum reactions the keynote got among journalists, analysts and non-developer entities. And of course the stock is down. Well, no new iPod was revealed, right? And some people to this day think that Tiger was only Dashboard, Spotlight and some small cosmetic changes in the iApps…

…and from that point of view, the Leopard preview was only Time Machine, 64-bit support on some machines, and… HTML Mail templates? To-do in Mail. And erh, more effects in iChat and PhotoBooth, right? Personally, I was disappointed to see Steve Jobs waste so much detail on such trivia. And of course, HTML e-mail should be stamped out, not fomented!! Death to Mail templates!!! Argh. Sorry. Hm.

Well, it’s a developer conference and this was a preview for non-developers. The timing of this conference was very interesting. I’ve been to conferences where the timing was unfortunate. Way back when they showed the Copland preview absolutely nothing worked and most of the sessions were pure hand-waving. Last year, Tiger had already been out for a time and that conference was interesting more for its historical value (and for testing on the Intel kits, of course).

This time, the Leopard preview is at the right stage. Most of the new APIs and things are either working or in the final stages. There’s documentation! There are machines running the new system! The new system kernel panic a few times a day under hard use, but that’s normal. There’s the usual list of deprecated APIs we should avoid in the future, and the usual list of cool new APIs I’ll have to wait a year or more to really use. What is mostly not there is what those guys were looking for: a new kernel, a new Finder, the death of metal, new applications, radically improved applications (and I’ll explain below why they shouldn’t be here now).

More importantly, there’s a clear sense of direction. I’ve changed several ideas I had about XRay II’s implementation and most of them will make my life easier, mostly through having to write less code. Or, in the future, of being able to take code away, or to do cool new stuff on Leopard in the “just-works” mode.

So, what the non-developers don’t get is that Leopard is all about infrastructure – as was Tiger too, come to think of it. As someone (Lincoln?) is reputed to have said, “if I have 8 hours to fell a tree, I prefer to spend 6 hours sharpening my ax”. And that’s what’s going on. They’re sharpening the infrastructure. Then, a very short time (comparatively) before release, all the new infrastructure will make doing those cosmetic and application changes much easier, and they’ll be faster as a side-effect too. And they’ll be doing things not possible today. Some folks are catching this hint. For instance, Time Machine’s cool new UI is possible thanks to the new CoreAnimation framework, which itself rests on other stuff I can’t mention… and all this new infrastructure is interacting synergistically, so the rate of change of innovation is increasing without Apple having to add more engineers, or developers like me having to write more code. The new boring Mail features are based on new frameworks available to other apps, and so on.

More later…

Looks like I got most of it right… Xcode 3.0. 64-bit cleanness. Dual duo-core Mac Pro (Xeons), also in the new Xserves. No iPod or iAnything.

No new UI stuff was visible, but Time machine and CoreAnimation makes up for that; these were really cool. No new Finder, it seems.

No virtualization, unless they’re keeping the name “Boot Camp” for that. Still, Steve Jobs said many features were still “top secret”. I suppose most of them will be revealed later under NDA.

More later. Or not.

Update: Xcode 3.0 features a cool new debugging feature called… “Xray”. So. Good thing I’m at XRay II already. Where’s my lawyer…?

So, I’m just back from getting my WWDC badge. I’ve seen the famous banner and all icons on it are known – the only one I had doubts on (above the SpotLight icon) is supposedly from a Mac OS X Server utility. Even the 64-Bit icon was previously used when the G5 came out. Ah right, we now know what the Leopard “Big X” looks like – black with a white border. Drat, I need to change the XRay II icon to reflect that…

The relative sizes and positions give no hints. There are a few hardware icons. One iPod Nano. 3 iMacs, 2 laptops and one desktop – the latter one from the side, so the front may be different. Or the banner might just be there as a misdirection and may be changed on Thursday… the Xcode icon is very large – so large that one can read the small print on it, but then it’s a developer’s conference. On the other hand, people “in the know” did tell me to make sure not to miss the developer tools sessions.

Certainly a major release of Xcode is in the works. 2.5 or 3.0, it doesn’t matter, but my personal hunch is that the superannuated Interface Builder application will be phased out and integrated into Xcode. Let’s hope that connections like outlets and bindings will be easier to visualize and debug, and that the IBPalette interface is finally officialized so that we can write non-trivial palettes.

I’ll be under NDA for details – things announced at the keynote excepted – so these will be my final pre-WWDC speculations. On the hardware front, 64-Bits is of course guaranteed, with one of the new “Core 2 Duo” chips. A Mac Pro will certainly be out, although the name may not be exact, and the casing will probably be a minor variation on the current one. There’s a good Ars Technica writeup about the new Intel CPUs, and expectations are that the whole new range will fit nicely into the spectrum from MacBook Pros to the Mac Pros – possibly with a dual-core, dual-CPU at the top, although it might also be that Intel has been reserving their quad-core chip for Apple to announce. Intel Xserves might also appear.

I don’t expect a new iPod to be announced in a big way, except as a footnote to the usual summing-up of past sales; at a developer’s conference, it’ll be big news only if it had an official API for developers to extend its functionality, which might actually be a neat way for Apple start a new iPod generation in a privileged position; stranger things have happened.

I’m reasonably certain that we’ll each get a Leopard preview DVD. I’ve seen rumors of changes to applications, which I consider less interesting as they’re not really a part of the OS itself, at least from my developer’s standpoint. I use relatively few of the iApps every day – Safari and iChat are the ones I leave open, and my wishlist for those is small.

Real Leopard features I expect to see:

– RBSplitView adopted! Well, not likely, but it’d be nice… I’ve told Apple I’d gladly give them the code, anyway.

– A new UI theme, or at least a migration of the default windows theme to the new “cool gradient/smooth metal” look.

– Some new Cocoa widgets, especially the more successful ones from the Tiger iApps. I hope to see them do Brent Simmon’s “big time tabs control”; I need it badly for XRay II.

– A new Finder. I’ve mostly gotten used to the old one, but still…

– Resolution independence. We need to get away from the pre-rendered bitmap widgets. People are already starting to use object-based PDF files for that, but they’re a pain to make and don’t look good at all resolutions. My ideal solution here would be a new NSImageRep and corresponding file format that would do for images what the TrueType format did for fonts: resolution-independence with special hinting for small sizes.

– More extensions to Objective-C. Garbage collection should be a given. Unloading NSBundles is supposed to be in the works. Frameworks included inside applications can’t be easily updated and versioning is pretty much useless for practical purposes.

– Hopefully we’ll see expanded metadata capabilities and a more useable SpotLight. I hardly use it in Tiger because it’s so slow and limited. The ability to have additional named forks should go hand-in-hand with full NTFS support. Other file systems would also be nice (ZFS, anyone?).

– Virtualization. I’ve written about this several times. My personal opinion is that Apple should write a fully trusted hypervisor into the EFI (using the TPM) and run everything inside virtual machines, including Mac OS X for Intel itself. Booting some version of Windows into a second VM would be easy, then, and there wouldn’t be a full version of Mac OS X for Intel for people to run on standard PCs either. I don’t think dual-booting is a good solution, I believe Apple was just testing the waters with BootCamp. No idea what would happen to Parallels in this scenario; they might be bought out by Apple, or by Microsoft, I suppose. Here are more thoughts on virtualization from Daniel Jalkut and Paul Kafasis.

– 64-bit “cleanness”. Meaning, Carbon and Cocoa and everything else running in 64-bit apps. And very probably, also, on the G5s. However, I’m not sure (and no time to research at this moment) how mixing 32 and 64 bits works on the Intel CPUs. I remember reading somewhere that it’s not as easy as it is on the G5, where you can have 32-bit processes co-existing with 64-bit processes.

Unlikely or even impossible:

– A new kernel.

– iPhone, iPDA, iGame, iTablet. iAnything in fact. There are rumors about VoIP support and there might be some sort of hardware for that, but I can’t see Apple doing a me-too cellphone.

– Some goodie under the seat (like when the iSight was introduced, which I missed out on, argh!).

In the meantime, I’d better get back to my coding… more after the keynote!

The week’s results have been good, though some important stuff still remains to be done.

The basic hex viewer is working, although selecting and copying text is not (yet), and I’ve reworked infrastructure for plug-ins and views once again. As usual, I’ve also gone through another round of cleaning up little UI details. So I’m confident that everything is in place for me to make serious progress during WWDC; especially regarding the list of questions I’ll have ready for Apple engineers.

In another hour we’ll be off to have lunch with friends, and afterwards I’ll be at Moscone West to get my badge and meet people. Look for the graying geek in the XRay II t-shirt…

OK, the XRay II file browser now works sufficiently well that I can leave it alone for a week or two, and get to (re!)doing the basic plugin stuff. It still lacks keyboard navigation and scrollwheel support, both of which should be easy to do. It still slows down when accessing a larger folder – or /Network – and I’ll probably have to make this multithreaded soon.

Other UI stuff that works now is dragging&dropping a single file onto the main window or the dock icon. Yes, there’s now a single main window and I’ll do tabs. Real Soon Now. While the idea of supporting multiple windows – like in the current XRay – was attractive at first, experience showed that people were liable to drop a hundred files at once, making the system freeze in an iterative spasm of ever-more-slowly appearing little windows. And very few people ever asked to be able to compare two files side-by-side, anyway. So I’m going for a large main window which will be able to show more stuff at once.

The latter change in direction is also in line with moving away from a (small) “better Get Info” window, towards showing file internals. Finally, having one browser for each window would also become heavy after 2 or 3 windows… not to speak of synchronization issues when the whole thing becomes multithreaded.

The plugin interface is still in flux, but I’m making headway on the basic simple ones: file attributes and metadata (well, some to start with), as well as hex dumps for data and resource forks. The problem is that all those have to converge asymptotically to a nice implementation over multiple iterations, and I won’t be sure of my basic design choices until they’va all been done at least twice…

Still, I’m confident that I’ll be able to show an alpha version at WWDC. Very probably at Buzz’s bloggers dinner net Monday.

Things are going well. I now have some confidence that I’ll be able to show a working alpha of XRay II at WWDC. Details later…

Also, I found this EgoSurf thingy on Mike Zornek’s blog. It’s some sort of link rank, so here it is without further warranties: