defaults write com.apple.Dock workspaces-auto-swoosh -bool NO

How Apple thought they would “subtly” change the behavior of Spaces from that of every other virtual desktop manager from the last 15 years, and not receive a ton of grief from their users, I do not know.

Keep the bug reports flowing, and let Apple know what we think. There are a lot of us asking for the same thing, and the fix is easily implemented; this bodes well.

While awaiting any official solution, “Spaces.. Spaces.. Spaces..” at seems promising.

Or, as I currently do, use Ctrl-F4: the shortcut to “Highlight Window (active) or next window behind it” (requires “Full Keyboard Access” to be on — toggled by Ctrl-F1). It cycles differently than Cmd-Tab, but shift reverses direction, so it’s quite ok. The combo itself is awkward though, so I changed it (in “System Preferences -> Keyboard and Mouse”) to alt-a..

By and large I’m working in one space with other Spaces configured for particular things. I have iTunes open in one space at full screen. Mail, iChat, Adium etc in another and so on. I want those apps there because having it that way fits my workflow.

If I happen to be in one of those spaces and then decide I want to open some random app to use in my work area I have to move it. This happens regularly. I would like to be able to say that everything will open in space 1 (for example) unless I have either allocated it somewhere else or I perhaps manually override it when opening so that it stays in whichever subspace I’m in.

Currently I find I have bits of apps all over the place and I have to remember to move them back or move to the right place first. I could go through every app and configure it to start by default in a particular place but that’s a pain.

Mark said:

When I select Safari (using Cmd+tab or the Dock icon) the default should be to switch, unless I specifically open a new Safari window in my current space, which I should definitely be able to do.

If you select “New Window” in Safari’s Dock icon menu does it open in the current space regardless of any preexisting Safari windows in other spaces?

So, instead of all Safari windows following me to each space I switch to with ‘Every space’ I could have a contextually applicable Safari window in more than one of my spaces. I think this would fix the issues with spaces as they are at the moment.

Definitely worth implementing though it won’t fix everyone’s issues.

…

Part of the trouble seems caused by borrowing pre-Spaces methods of app switching for space switching. For me it’s less confusing to keep them distinct instead of anticipating if invoking an app switch will also cause a space switch, and to which one. The tradeoff is having to remember which space to switch to, or keep switching until its reached.

And the “app switch may create new window” behavior, which some people rely on, doesn’t integrate particularly well with Spaces.

Likely it’s impossible to get consistency in all cases with Spaces, especially without any app-specific support, but certain improvements would definitely get closer to that goal. And with dubious changes it might end up suffering something analogous to Finder’s spacial vs. browser identify crisis and John Siracusa can start writing about that for a change.

Firstly, I think the auto-space switching is an essential feature. To use your example, say I’m in space 3 and I have Safari open in space 2. Though I might want a new Safari window in my current space, aren’t I more likely to want to look at something I’ve already opened in Safari in space 2 where I’ve been browsing? When I select Safari (using Cmd+tab or the Dock icon) the default should be to switch, unless I specifically open a new Safari window in my current space, which I should definitely be able to do.

‘Allow instance in every space’ is different to ‘Every space’ in the following way: ‘Every space’ keeps all windows of a particular app in all spaces. ‘Allow instance in every space’ would let me spread different windows of the same app (multiple Safari windows for example) across different spaces. So, instead of all Safari windows following me to each space I switch to with ‘Every space’ I could have a contextually applicable Safari window in more than one of my spaces. I think this would fix the issues with spaces as they are at the moment.

Overall this is a very interesting issue, as I can see two distinct ways of thinking about Spaces … and I actually operate both at once! One way sees a particular space based on a task. I have Thunderbird always in Space 3 for example. This is a task-oriented uses of spaces. My IM app might sit nicely in this space too if I used one. Looking at the other way, I also keep spaces 1 and 4 for real work where stuff contextual to that work goes on. These are looser, context-oriented spaces where all sorts of apps relevant to what I’m doing can reside. Honouring both these ways of looking at spaces is quite a challenge: the first requires switching spaces, the second not switching spaces. This is further reason why ‘Allow instance in every space’ is a more suitable workaround than retarding the automatic space switching.

Thanks for sparking off this debate. It proves, at least, that more thought needs to go into Spaces and Apples UI people should look at it more closely. That said, Spaces at this stage are still more powerful and pleasant to use than the Linux equivalents that have been around for years.

Your description doesn’t quite match the way it worked for me during brief testing at the Leopard launch, but I’m more interested in how you prefer it to work and I think you made that point.

Tricky handling cases like “app1 opens app2 window (or launches app2) in current/other space in foreground/background with/without app/space switch”.

I think Spaces handles command-click on a link in a Mail message by opening a browser window in the background without doing an app/space switch. I’d consider that well-behaved, even if you don’t like it. Not sure what it does if the browser’s not running; will its launch cause a space switch if the app is bound to a non-current space? If so, I’d consider that ill-behaved, even if you like it, because it requires thinking about whether or not the browser is currently running to predict what’ll happen. If the expectation is that command-click doesn’t do an app/space switch than a special case where it *does* do an app/space creates inconsistency.

That’s not meant to be an obscure hypothetical example; cases like it are common with intra-app communication and one reason why Spaces’ (et.al) auto-switching can be a nuisance. I’d like a well-defined, consistent way of doing “app1 talks with app2 in the background” actions.

Could be interesting comparing working styles and experience of people who prefer space auto-switching to those who don’t. I wonder if people comfortable with classic Mac OS app/window hiding/switching interaction might be more prone to like auto-switching while those who’ve used other vwm’s to manage apps/windows would rather have explicit switching. I’d get more value from discussions like this with a better understanding of how other people actually used their systems.

| I don’t! Re-read what I wrote.

I know *you* don’t. My point is, if virtual desktops were around when Safari was first written, it is a question that the the developers would have asked themselves. The Safari developers would have known, had it come up at the time, that shifting people to a different desktop just for the Safari Download window is excessive and perhaps even obnoxious.

Just sayin’, it’s not all up to Spaces, the app developers have work to do too.