The science behind Spaces

Spaces, as I’m sure you’re aware, is one of Leopard’s headline features and (finally) adds virtual desktops to Mac OS X. AppleInsider’s “Road to Leopard” feature covers Spaces in quite some detail from a user perspective, but what about from a developers point of view?

As it turns out, there’s a fair bit of history behind virtual desktops on Mac OS X, even though they’ve only become officially supported in Leopard. Over the years, there have been at least three implementations of virtual desktops on OS X, including Desktop Manager, VirtueDesktops and VirtualDesktop Pro.

Crucial to the emergence of the first two of these virtual desktop solutions is Richard Wareham, who did some sterling work on reverse engineering numerous private Core Graphics (CG) system calls. (Core Graphics is an umbrella term that includes Quartz 2D, Quartz Display Services and Quartz Events Services and is often used interchangeably with Quartz.)

Wareham was the sole developer behind Desktop Manager, which relied on his CG reverse engineering for the core of its functionality. He kindly made his work freely available to the developer community in the form of CGSPrivate.h, a header file containing the low-level graphics calls he’d uncovered. In 2005, Wareham actually wrote an OSNews article about some of his reverse engineering efforts when he was updating CGSPrivate for Tiger.

So Desktop Manager was, in Wareham’s words, the “original ‘virtual desktop on a cube’ application for OS X”. A little later, sometime in mid-2004, Thomas Staller made public a Desktop Manager rival project called VirtueDesktops, based in part on CGSPrivate.h (and, like all the aforementioned virtual desktop managers, Wolf Rentzsch’s mach_inject for Dock code injection — unsupported virtual desktops are a messy business if you’re not Apple!). VirtueDesktop development stalled for a while, but was revived in late 2005 by Tony Arnold who worked alongside Rentzsch to get it working under Tiger. There’s a great post Spaces-announcement interview with Arnold on MacApper, which reveals a lot of history about virtual desktops on OS X.

Specifically, Arnold shares two interesting titbits: 1. The Core Graphics calls that Wareham uncovered (the likes of CGSSetWorkspaceWithTransition and CGSGetWorkspaceWindowList) have been present “for at least 2 major revisions” (which I interpret to mean pre-Panther) and 2. Arnold “heard unsubstantiated rumours from a very credible source that Apple has had virtual desktops working internally for longer again.” So it seems that Apple has been working on underpinnings of Spaces for a fairly long time.

How exactly Spaces is implemented in Leopard remains a mystery at the moment, although it would be fair to expect that Apple is building on the functionality exposed in CGSPrivate.h possibly with a bit of Core Animation magic thrown in…

From a third-party developer point of view, there’s a surprising scarcity of programmatic access to Spaces. There is only one class, NSWindow, that has been updated with Spaces-specific methods: -(void)setCollectionBehavior: and -collectionBehavior. These determine whether a window appears on all Spaces (like the menu bar), moves to the current Space (like the Find panel) or just stays put on one Space (like a document window). There’s no (public) programmatic method to switch to a different space (without resorting to clumsy AppleScript), discover the current space or move a window to a difference space.

On the positive side, this does mean that windows won’t be flying around the place at the whim of developers, but it is a bit of a shame that haven’t given developers access to this. Doubly so considering that there’s no native “bringAllDocumentsToSpace:” method in NSDocumentController (or NSWindowController or anywhere).

Anyhow, developer woes aside, it’s great to see virtual desktops finally built in to OS X and (for me, at least) it’s been quite interesting to read how the various third parties had bravely implemented it in previous versions.

Safari enhancements


Improved element inspector


Automatic image downscaling

Two-up PDF viewing

Mobile Safari user agent string

A little more on resolution independence

After a bit more digging around, I’ve basically found two major apps that sit at either end of the RI-ready spectrum. First off, Safari seems to be very well prepared for when the RI switch is flicked (just need to sort out those Bookmark bar triangles!):
(click to enlarge)

Notice how the button style actually changes: at 72 dpi, the buttons are more metallic than at 216 dpi (above) where they have a more “Aqua-esque” appearance.

iTunes, on the other hand, is just “magnifying” its entire interface rather than using genuine scaling. It’s also using Tiger-style window widgets:
(click for full screenshot; 2180 × 1652)

So, all in all, a decidedly mixed bag…