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.

Preview GPS tag support

I’m sure this has been mentioned elsewhere, but I was a bit curious as to why the Leopard version of Preview (version 4.0) has an about box containing a link to a NASA webpage:

Preview 4.0 about box

All is revealed when you open a photo that contains geographical tags (longitude and latitude) in the Exif data. Such tags can be added using a program like Geotagger (requires Google Earth) or may be added automatically by the very few available cameras with built-in GPS.

So here’s what it looks like when such tags are in place (the image, incidentally, is of my alma mater, Trinity College, Cambridge):
preview-geotag.jpg
(click to enlarge)

Conveniently, pressing the Locate button at the bottom of the Inspector window opens the location in Google maps.

The map image itself is actually stored deep within the System folder, specifically in the ImageKit framework resource folder: /System/Library/Frameworks/Quartz.framework/Versions/A/
Frameworks/ImageKit.framework/Versions/A/Resources.

This isn’t that interesting in and of itself, but there are in fact 12 map images (each 600 x 300 pixels) in that folder, each portraying the earth with differing amounts of snow coverage! Are these maps used anywhere else in Leopard? The Time & Date preferences panel has yet another map of the world in the TimeZone.prefPane bundle, so they’re not used there…

Talk on BioSAVE: Cambridge, Thursday 18th October

I’ll be giving a brief talk (10 minutes or so) on the development of my BioSAVE (Biological Sequence Annotation Viewer) program for Mac OS X at The Cambridge Computational Biology Institute (CCBI) this coming Thursday.

The talk will focus on OS X as a platform for rapid application development and a little bit on what BioSAVE can actually be used for. A poster advertising the meeting can be found here (PDF; 364 Kb).

The CCBI is located here:

View Larger Map