Spaces in 10.5.3

Friday, 30 May 2008

Spaces was one of the new features in Leopard I was most excited about, but I found the actual implementation unusable. Henry Story wrote a fine description of the problems with Spaces in 10.5.0. When I linked to his critique, I wrote:

I’ve tried to love Spaces but can’t, because I want to divide spaces into tasks, and some apps, like my web browser, need to have windows in every space. If I’m in, say, space 3 and Command-Tab to Safari, I want Safari to activate in my current space, not jump me to whichever space contains the frontmost Safari window. In short, Spaces seems designed for app partitioning, not task partitioning.

Take, for example, the task of writing this article. What I want to be able to do with Spaces is dedicate one space solely to the task. I want Safari windows pertaining to any web pages related to the article, and MarsEdit and BBEdit windows for the article itself. But I don’t want all open Safari, MarsEdit, and BBEdit windows in this space — I only want those pertaining to the article. There was simply no way to make this work in 10.5.0 through 10.5.2; you could get the windows grouped this way, but you’d keep getting switched to another space when what you wanted to do was switch to another app within the current space. Spaces really only seemed suited to putting all of any given app’s windows in a particular space (or making all an app’s windows visible in all spaces). This isn’t to say Spaces wasn’t usable, only that it wasn’t usable for grouping a few windows from different apps together in one Space.

This week’s release of 10.5.3 brought good news: Apple has addressed this problem with a few seemingly minor changes to Spaces. Apple’s release notes for 10.5.3 hint at the changes, but don’t explain them in any detail:

Spaces

• Resolves an issue in which switching to a different space and returning back to the original space may reorder the application windows with a different active window.

• Resolves an issue in which activating an application from the Dock switches to a different space, even if there is a window for that application in the current space.

• Fixes an issue in which Command-Tab may incorrectly switch to a new space.

• Addresses reliability issues with Spaces when syncing preferences over .Mac.

Some of these are simply bug fixes. Clearly, for example, switching between spaces shouldn’t have changed the window ordering within a space. But some of these describe new behavior which only kicks in if you turn off a new-to-10.5.3 checkbox in the Spaces panel in System Preferences: “When switching to an application, switch to a space with open windows for the application”.

By default, it’s checked, which means app switching under Spaces remains much the same as it was on 10.5.0–10.5.2. For example, let’s say you have two spaces, with one or more Safari windows in space 1, and no Safari windows in space 2. If you’re in space 2 and activate Safari — whether by clicking the Dock icon, Command-Tabbing, or opening a link in some other app’s window in space 2, then Spaces will jump you to space 1, where there are already open Safari windows.

If you turn this new checkbox off, however, activating an app, even one that has no windows in the current space, will not jump you to another space. Once you’re in a space, you stay there until you explicitly switch spaces, not just switch apps. This makes all the difference in the world for the way I, and others, want to use Spaces.

This is a major change to the way Spaces works, but the checkbox label doesn’t exactly make it clear. (I don’t have a better label to suggest; it’s a tough feature to describe in the length of a checkbox label.) Sadly, the help content for Spaces does not seem to have been updated to even mention this checkbox, let alone describe what it does.

One non-obvious detail is that you can switch to another space by clicking an app’s Dock icon multiple times. If you click a running app’s Dock icon once, that app will activate in the current space. If it doesn’t have any open windows in the current space, it will activate without creating a new untitled window. But if you click that same app’s Dock icon again, you’ll jump to the next space in which that app does have an open window. If the app has open windows spread across multiple spaces, subsequent clicks on its Dock icon will cycle through those spaces. So if you have four total spaces, with Safari windows in spaces 1 and 3, you can repeatedly click Safari’s icon in the Dock to cycle between spaces 1 and 3. If you’re starting in space 2 or 4, clicking Safari’s Dock icon once will activate Safari in that space but without a window.

Using Command-Tab to switch between apps, you will never automatically switch to another space when this new “switching” checkbox is turned off. (It’d be nice if the Command-Tab window provided some sort of indication for which apps have open windows in the current space.)

I also ran into an issue specific to web browsers. In the General tab of Safari’s preferences window, you can specify whether links from other applications open in a new Safari window or in a new tab in the frontmost existing Safari window. I had been using the “in a new tab” option. However, with this new Spaces feature, opening a link from another app in a space that has no Safari windows will jump you to the next space that does have one. Ideally, I’d like to see Safari create a new window in the current space in this situation, but as it stands, changing Safari’s preference to open links in a new window is good enough. (This same thing applies to other tabbed web browsers, such as Firefox and Camino.)

In short, if you were happy with the way Spaces worked through 10.5.2, you shouldn’t notice any changes, because the default behavior remains the same in 10.5.3. But if, like me, Spaces drove you nuts by switching between spaces when you only wanted to switch between apps within the current space, give it another shot after turning this new checkbox off. Kudos to the Spaces team.

---

Lastly, I should mention that I had problems getting this new feature to work at all. After upgrading to 10.5.3 and seeing the Spaces-related changes in the release notes, I tried it out. Toggling the new checkbox made no difference for me, however — I got the same old “jump to another space when switching apps” behavior either way. I solved the problem by trashing my com.apple.dock.plist preferences file (which, since Spaces is controlled by the Dock, is where most Spaces-related prefs seem to be stored). After logging out and logging back in, the new checkbox worked perfectly.