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

Aside from the improved “resolution independence readiness” and the features on the so-called Sparta list, Safari has seen a couple of extra enhancements:

Improved element inspector
This new inspector has been in the nightly builds since June and is a massive improvement over the previous HUD-style inspector. To my constant amazement, the whole inspector is implemented in Javascript, CSS and HTML and looks like this:
web-inspector.png

It really is a brilliant tool, particularly the global text search field, HTML syntax highlighting and, as shown in the image above, the resource load timeline.

Automatic image downscaling
Finally, Apple has added automatic image resizing when a single image is loaded in a Safari window. Now, when an image is loaded into a Safari window that is too narrow/short to display the whole image, it is scaled down to fit and the mouse cursor changes to a ‘+’ magnifying glass.

Two-up PDF viewing
As well as the advertised PDF HUD (so many TLAs!) interface for zooming, opening in Preview and downloading, Safari in Leopard sees the addition of an option to view PDFs two pages abreast, which is nice for those people with larger screens:
2-up1.png

Mobile Safari user agent string
If you like your Safari with its Debug menu on (defaults write com.apple.Safari IncludeDebugMenu 1), there are a couple of small additions here as well. The first is the addition of a “Start Stress Test” menu item – not massively exciting. The second is the addition of “Mobile Safari 1.0” (and indeed Safari 2.0.4) as a User Agent option, so you can fool websites into thinking you’re browsing from an iPhone or iPod touch. Might be useful on the odd occasion…

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!):
safari.png
(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:
itunes-widgets.png
(click for full screenshot; 2180 × 1652)

So, all in all, a decidedly mixed bag…