Pascal’s Diary

This might be the greatest idea I’ve heard in a while. I wonder if there’s any way of getting Apple to hear about it?

“So if you’re in space 3 and you want to look at that Ebay auction item that’s open in some other space, you could choose the window from Safari’s Windows menu, or from Safari’s Dock menu, and it would swoop into view in your current space, keeping you in place, not disrupting your workflow or your context.”

But it would be destroying the Space you already set-up. If Spaces is removing windows from Spaces all willy-nilly, then what purpose do Spaces even have: they are unreliable and inconsistent.

I think adding this little checkbox to let Spaces behave one way or the other is GREAT. However, I don’t think you can really justify that Spaces behaving the way you want is “better” than the way it currently behaves. They have different philosophies (and I think the default Apple behavior is much more consistent than what you and others are asking for), but your “power-user” and “grandma” comments are a bit snobby.

Essentially, it seems like people are pissed they can’t use Cmd-Tab to open new Windows, which is essentially saying they are pissed that when they switch applications with an application-switcher Spaces attempts to switch applications and nothing else. Instead people ant app-switchers to open new windows and Spaces to reorganize things all on it’s own, which for my money is a usability nightmare as consistency is thrown out the window.

Pascal, I’m the author of Jumpcut (just clicked through from Daring Fireball and got a kick out of your screenshot) — have you actually experienced any problems to date with how JC and Spaces interact? I just picked up a copy of Leopard and haven’t started experimenting yet.

Okay, Mom, not Grandma. Same difference

Agreed. With other pre-Leopard window managers, you didn’t get the auto-switching behavior. While it can be annoying that something happened while you were not looking, it prevents the switching back and forth that I find annoying.

Is it annoying enough to give up on spaces? No. Your suggestion sounds like a winner.

Thanks for writing this blog dude. This is exactly what I hated about spaces and the reason why I switched it off.

If Apple end up doing what you are suggesting I will probably turn Spaces on again. Until then, it isn’t really useful. Just frustrating.

Elegant, simple solution.

One question: how would it handle apps bound to specific spaces? If I’m in Space 1, and Safari is bound to Space 2, what happens when I click the Safari dock icon? Seems to me it would have to be an exception and switch the space, as is the current behavior.

Note that *this is already possible* if developers use the new APIs in 10.5, in particular ‘s NSWindowCollectionBehaviorMoveToActiveSpace which does exactly what you want.

Sounds like a new feature request for Afloat

I think this is indeed an excellent idea. Another suggestion I have seen is to have that a per-application setting (can’t find the link anymore, but basically it is just adding the “Current Space” option in the drop-down menu in the table view), which I like even better. Automatic switching is what you want for certain apps like iTunes or Skype or Software Update, where you only really have one window, and you want Spaces to bring you to it when you invoke the app.

I think the essence of the problem and what gets me really annoyed is that the behaviour of Spaces is **surprising**. A user interface should never do something that surprises you. This is very disruptive. On top of that, there is no “Undo” that gets you back to where you were before (unless Exposé or Dashboard that can surprise you if you hit the key by mistake, but you press the key again, you are back).

Ah, found the link!

http://blog.elliottcable.name/articles/2007/11/spaces-solution

The URL didn’t get pasted: NSWindowCollectionBehavior and setCollectionBehavior

Sounds just about the perfect solution. Congratulations: it scratches the mental itch which seems to be the same for most Spaces users.

I’d also like to see a menu bar pager like the one Desktops Manager (and most flavors of Linux) offers. This is how I’ve been switching between desktops for nearly three years, and to lose this feature in Spaces would be a real loss of functionality for me. Either Apple implements it or someone codes a hack — I don’t care, just as long as my move to Leopard includes it.

The only problem I see is how does one deal with floating windows, such as Illustrator tool window palettes. Ideally this would be handled by detecting floating windows in Spaces and having them show up in all spaces where there is a document window open. But I have a feeling some applications are not very well behaved and having Spaces sort out which windows are floating may not be all that easy.

One possibility would for Apple to add a “Spaces aware” flag and an API so that they can leave it to applications to indicate that they need to move their own palettes; dunno. But I can see a bunch of applications with auxiliary windows like palettes that this could break…

Bringing up windows on other spaces without some visual feedback would be terribly confusing to many. I would add the requirement that windows opened in other spaces give some sort of visual feedback on the current screen ( arrow, spaces menu item blink with window number, .. ).

I think the suggestion by elliotcable at http://blog.elliottcable.name/articles/2007/11/spaces-solution is the best one so far. The current implementation really does make sense for some applications, and I think it makes more sense to choose non-switching apps manually. However, your I like your idea that with autoswitching off, the window comes to you instead of the other way around. Ultimately though, that ought to be some sort of API call by the app developer…

I’d also like to see the ability to change my background image or color per space as a quick identifier for which space im in. Maybe that’s there and I just haven’t found the feature yet?

Totally agreed. An elegant solution.

[...] http://www.pascal.com/diary/?p=183.  The idea basically is to provide an option for power users that would stop Spaces from ever switching your space for you.  If Safari is open in space 1 and you’re on space 3 and click on Safari in the Dock, it would open a new Safari window for you, rather than darting you over to space 1.(via daringfireball)  [...]

Excellent suggestions! I used VirtueDesktops for a long time but quickly stopped using Spaces for just this reason. The “bring it to you” would be icing on the cake.

Good point. This is what CDE had all the time. The good thing was you never were able to see all the workspace at the same time.

If a finder window appears in all the workspaces, and you hit F8. What happens now? When you click on a window and move it from one space to another — do all of them move at the same time? Like as if they are linked together? That’s a possible way to implement.

Or simply show them in a different shade (so one can see it clearly that it cannot be moved from one space to another as it is already present in all the windows). or F8 can simply ignore the common windows!!

There’s another way to put a “common space”, but that would make things a bit more complicated. Windows in common space will appear on all spaces.

I personally like the first one.

Exactly right! Good thinking. Now how can this really substantial idea be communicated with the engineers working on spaces?

As long as this means that URLs clicked in non-browser apps (IM windows, for example) will open the links in a newly-created browser window in the current space, I’m sold on the idea.

Spaces, by default, is intended for power users. For example, my wife, who is the quintessential casual user, wanted nothing to do with them. I showed her how they worked, and how they “uncluttered” her desktop, and she could have cared less.

While I don’t think your suggestion is a bad one, I also don’t see the problem with the way they work now. Personally, I’d much rather have the space change when I click on app that I have assigned to a particular space, than have the apps window move to where I am. I don’t want my apps moving windows without my intervention. But, that’s just how I roll.

I don’t mind Spaces switching when I click an application in another window. I think that’s a nice feature, so I can go directly to that application and not have to switch to another space. HOWEVER, I *DON’T* want Spaces to switch automatically when an application in another space puts up an alert or displays a sheet. It’s *especially* annoying when I’m running Windows with VMware and Outlook shows a new mail alert.

[...] http://www.pascal.com/diary/?p=183 [...]

To the one who asked if there was any way for getting Apple to hear about it: Yes, there is. You can file a bug/enhancement request.

Apple reads them all.

http://developer.apple.com/bugreporter/ is your friend. It’s always better to file a bug (or enhancement request, whatever you want to call it) than just complain about it on blogs. Always.

[...] have been a lot of complaints and criticism about Spaces in Leopard, particularly with how it switches spaces when you switch [...]

I think your option, though needed, should not be necessary for the Safari Download window. The window is just a utility, a notification really, why would you ever want to shift desktops just because of it? Also, would it make sense to put the Download window moving code in Spaces or in Safari? Meaning, is there a certain type of window that should always follow you or should the application decide that a window should follow you? Really, these are the kinds of questions that application developers now need to deal with.

I think some of the trouble is the applications, not Spaces itself. (Granted some of those applications are written by Apple.)

For example, my biggest problems so far have been:

1) The “save changes before quitting?” window/dialog (I’m not up on OSX windowing terminology). If I have a few Numbers documents open on different desktops and I try to logout, this can show up on a desktop I’m not looking at causing the logout to stall for no visible reason. Sure, the dock icon might jump, but if I have two unsaved documents on different desktops I will still be greeted with some unnecessary confusion.

In this case, should Spaces be alerted to the fact that there are windows that need action on multiple desktops or should the application be aware that the user may not be looking at the window that needs action?

2) The TextMate “Find” window. I often have multiple TextMate sessions on different desktops, sometimes the “Find” window will show up on the wrong one. Should Spaces move the window to the TextMate session I’m looking at, or should the behavior of the Find window change? Perhaps associate it more directly with individual sessions and not just pass around a single window?

My point is that virtual desktops provide a fundamental shift in the way you have to think about how the user interacts with your software. You can’t just let Spaces handle it, the application has to change as well. I’m not blaming the application developers, I’m just saying that all the blame does not rest on Spaces itself… I think it will take a number of revisions on all sides of the table before we get a real Apple-esque user experience here.

Make sure to file an enhancement request:
https://bugreport.apple.com/

Anonymous at 1:37pm said:
“But it would be destroying the Space you already set-up. If Spaces is removing windows from Spaces all willy-nilly, then what purpose do Spaces even have: they are unreliable and inconsistent.”

It wouldn’t be destroying the spaces automatically or arbitrarily — It would be at the user’s behest. For example, say I’m in space 3, and there’s a window in space 1 that I want to see. If auto-switching was turned off, I’d have 2 options: I can switch to space 1 and see the window in that context. OR, I could select the window from the Safari’s Window menu and bring it over to space 3, so I can look at it side by side with what I’m already doing in space 3. This second option would essentially be the same as invoking the Spaces metaview and moving the window to space 3, but it’s much simpler and less disruptive.

In the first case, as a user, I’m saying: “I need to go look at that window where it is, in the company of the other windows in that space. I don’t need to see these windows in space 3 anymore.” In the second case, I’m saying “I’m here, with all these windows in space 3. I like where I am, I like these windows. But I want to compare something in that window over there in space 1 to something in one of these windows here in space 3. So bring me the window, and don’t make me jump through hoops to get it.” Both are scenarios that any user will encounter when using Spaces, and both scenarios need to be addressed and accommodated by Spaces.

To address some of the other comments here: it’s important to remember that this solution would not change a thing about how Spaces works by default. If you like how it works now, then you can simply leave auto-switching turned on and be happy with it. This additional option would simply add some flexibility to Spaces that would make it more useful for those who don’t like how it works now.

Also, I did not mean to disparage the utility of auto-switching, I’m simply saying it doesn’t work for all users. I may have miscast it by implying that only newbies could find auto-switching useful, and I apologize for that. Certainly there are plenty of experienced users whose workflows jibe very well with how Spaces works currently. However, I do maintain my assertion that Apple’s primary motivation in making Spaces auto-switch is to keep people who are not accustomed to virtual desktops (probably 90% or more of their userbase) from ‘getting lost’ and losing their windows. This is the same company that still ships every new Mac with a single-button mouse, after all. (And I’m glad they do — for the same reasons that I think Spaces should have auto-switching enabled by default.)

How would this handle single-window apps like iPhoto? Would it bring iPhoto into the current space, or switch you to where iPhoto is, breaking the “don’t switch spaces automatically” rule? And what of my earlier question about apps bound to specific spaces? Same thing?

Steve, I’ve found that Jumpcut is working fine in Spaces, having assigned it to all spaces.

And there is a third party hack called “Spaces…Spaces…Spaces” from http://www.scsc.no/products/spaces-spaces-spaces/

that when enabled prevents space switching and is working nicely here for me

Bill Woody says: “The only problem I see is how does one deal with floating windows, such as Illustrator tool window palettes.”

Apple already figured this part out, and it works great in Spaces already. Toolbars and palettes (in Excel or Illustrator, for example) automatically appear in all spaces. No work was required of Microsoft or Adobe for this to work. That alone is a testament to how good Spaces already is. But it can be better!

Tom von Schwerdtner says: “The [Safari Download] window is just a utility, a notification really, why would you ever want to shift desktops just because of it?”

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

when i heard about spaces i envisioned it being like have 4 (or more) separate “computers” on one. hopefully this gets implemented and becomes more like what id like.

Your first idea is for each space to act “truly like a new monitor, a new workspace, oblivious of its partners.” I like the sound of this, but it conflicts with your second idea: “invoking any window that is already open in another space would bring it to you in the current space, rather than swooping you over to it.”

How could you have each space act independently and at the same time allow them to steal each other’s windows?

The current implementation will NEVER move windows between spaces on its own – you have to do so yourself. That means if I put a specific window in a specific space, it will ALWAYS be there unless I decide otherwise. I can always get to it easily because I know which space I keep it in. But if the window I wanted MOVED to the current space, that muscle memory would be completely broken.

dave says: “How would this handle single-window apps like iPhoto? Would it bring iPhoto into the current space, or switch you to where iPhoto is, breaking the “don’t switch spaces automatically” rule? And what of my earlier question about apps bound to specific spaces? Same thing?”

You raise two very good issues there: with auto-switching off, what becomes of app-space assignments in the Spaces prefpane? And how should single window apps like iPhoto be handled? After thinking it through, it seems there is a single answer to both questions.

I think for the most part, with auto-switching off, app-space assignments become largely unnecessary. That’s not to say they should be disabled or removed, however. Suppose you have auto-switching turned off, but you assign Mail to space 2. What should happen when you switch to Mail? I think logically the answer here is to respect the assignment and auto-switch to space 2. (If you don’t want Spaces to auto-switch to space 2 when switching to Mail, then why would you assign Mail to space 2 in the first place?)

Following that through, I think the solution for single-window apps like iPhoto or iMovie is clear. If you want to auto-switch to those apps, then you should assign them to a space (or every space). That way, even when auto-switching is turned off, switching to iPhoto will always bring it into view. Obviously that requires the user to do some configuration, but they’ve already taken the step of turning off auto-switching, so I don’t think it’s unreasonable to ask them to do come a little further. Apple could make this a little easier by adding a menu command to each app’s Dock menu that reads ‘Assign to Space 1′ (in the same way that the ‘Open at Login’ option saves you a trip to the Login items section in your account preferences).

Obviously that’s not ideal, but I think it’s a good compromise in exchange for the ability to stay in the current space when you want to.

One addition. Besides “switch space automatically”, it would be useful to also have “switch applications automatically”. As it is now, if Word is active in space 1 and I switch to space 2 where Safari is frontmost, Safari becomes the active application. Then switch back to 1 (which also has a Safari window), Safari will now still be the active, even though when you last left the space, Word was active.

Seems like by making both of these behaviors optional, you can pretty much make spaces behave sensibly.

bongoman says: “there is a third party hack called ‘Spaces…Spaces…Spaces’”

I was really excited when I saw that a couple days ago, but unfortunately it doesn’t work when you use Quickeys shortcuts to switch apps, as I do (A LOT). I left a note on the developer’s MacUpdate page about that problem; hopefully they’ll find a fix.

daGUY says: “How could you have each space act independently and at the same time allow them to steal each other’s windows?”

I don’t think of it as stealing. The computer isn’t doing it on its own — it’s doing it when you select the window from the Window menu. You’re actively choosing to move it to the current space. If you don’t want to move it to the current space, then you should switch to the space the window is in, or leave auto-switching turned on.

and daGUY also says: “The current implementation will NEVER move windows between spaces on its own – you have to do so yourself. That means if I put a specific window in a specific space, it will ALWAYS be there unless I decide otherwise.”

Similarly, the proposed modification would NEVER switch spaces on it’s own — You’d have to do so yourself. That means if I switch to a specific space, I will ALWAYS be there until I decide otherwise. And again, it’s a checkbox. If you prefer the current behavior, leave the checkbox checked.

@Pascal: I see your point. In essence you’re just automating the process of switching to the overhead view and dragging the window over to the current space yourself. I get it now.

I personally would never want it to work like that, but I suppose that’s why you suggest it be implemented as a simple checkbox

Using the dock as a switcher between virtual desktops is the ONE feature that I found on MacOS implementations of virtual desktops that I was hoping would make it into Spaces. It’s the one thing that has made Virtual Desktops workable for me. I have been using various implementations like FVWM, Gnome 1 and later, KDE and later since the late ’80s. I migrated to desktops like wm2 and wmx on linux and ignored desktops.

So if Apple will just fix whatever the bug is that switches desktops for Firefox but doesn’t make the Firefox window active I’m a happy camper. A happy ‘power’ camper that is . I glad you didn’t fall into Gruber’s trap of assuming that there is only one true ‘power’ way of doing things Nice solution – extending the flexibility is a good compromise.

Like this a lot, although I like spaces I too am already getting tired of “whooshing” from one window to another when sometimes that isn’t what I want to do..

I’ve not trawled all the comments, so this could have been mentioned, but …

… rather than pull apps into a space to maintain context wouldn’t it be more useful to add an extra option to an application’s entry in the ‘Application Assignments’ box that was something like ‘Allow instance in every space’? … For apps that can support this at least.

The problem with globally turning off ‘Switch spaces automatically’ is that you lose the benefit of keeping an app in one space: Cmd+tab will end up giving me everything in one space and I lose the value of having spaces.

For example, ‘Allow instance in every space’ could give me a different Finder window in every space contextually applicable to the stuff going on there. Maybe some apps can’t have instances running in multiple spaces. If so, switching to their space should be fine. I wouldn’t expect to have Photoshop in more than one. For core apps that do support multiple instances, like the Finder, or a browser, I should be able to have multiple instances (or separate windows) in different spaces at the same time.

Very elegant solution, let’s hope they pick it up! In the meantime, my clunky workaround for the ‘browser window in every space’ need is to designate a different browser to each space. Space 1 has Firefox, Space 2 Camino, Space 3 Safari and Space 4 Opera. Yeah I know, it’s not ideal…

Many people are so eager to comment this and that, on new software. That is, before trying to get used to the new ways or ideas and dig through their geniality. Well the apple developers i’ll take it are also power users. They might also have thought this and chosen not to go this way.
Hack for your self, but stop making big wishes for everybody.

Mark says: “The problem with globally turning off ‘Switch spaces automatically’ is that you lose the benefit of keeping an app in one space: Cmd+tab will end up giving me everything in one space and I lose the value of having spaces.”

I don’t see why that would happen at all. Switching to an app wouldn’t automatically move all of its windows to the current space. Read the 5th paragraph of the article again.

As for the suggestion of an option to ‘Allow instance in every space’, I’m not entirely sure what you mean. Can you explain further? How is this different from the ‘Every space’ option? (I think I know the answer to that.) But how is it different from leaving the app unassigned altogether?

Stepping back a bit, I think any solution that requires the user to visit the prefpane a lot is a bad one. With auto-switching off, the main gotcha is single-window (or primarily single-window apps) like iPhoto or Mail. But I think that could be addressed by allowing per-app auto-switching to be enabled, as I described in a previous comment, by assigning apps to a space.

For example: you could turn auto-switching off globally, but still assign iChat and Mail to space 2, creating a ‘communication’ task-space. If you’re in space 3, clicking iChat or Mail would switch you to space 2 automatically. But clicking Safari would keep you in space 3, since it’s unassigned. So you could use app-space assignments to have it both ways, allowing automatic-switching for some apps while allowing other apps to respect your chosen space.

Obviously the Spaces prefpane would have to be reworked in some way in order to make clear what the resultant behavior would be when turning off auto-switching while still allowing auto-switching for app-space assignments. I suspect that the UI change shown in the screenshot above would not fully suffice. But it could be as simple as relocating the auto-switching checkbox and accompanying it with a short, well-written note.

The whole discussion had made me think more, and it seems the consensus is that there are 2 type of apps:

- the apps that naturally fit to only one task, either because they only have one window anyway, or because of the user feeling about it (e.g. for occasional coders, Xcode would be always in one Space, but for persons for whom it is a living, several projects may mean several Spaces)

- the apps that require the auto-switching off; on the top of the list, would be Safari, then probaby the Finder, a text editor,…

For the first kind, the auto-switching is great. For the end kind, the auto-switching is really really annoying and counter-productive.

Depending on your point of view, the first kind is the norm, and the second kind is the exception. Or vice- versa. This blog entry seems to think “vice versa”. Again, I think a per-app pref is the best way to support both views in a flexible way, without changing the UI and without requiring too much explanation to the user.

A minor issue is for panels such as Downloads, Find panel, Documentation window,… These should be addressed by the corresponding 3rd party developers (Safari people, the Downloads window, do you really work at Apple???). And it seems there is API support for that.

charles says: “A minor issue is for panels such as Downloads, Find panel, Documentation window,… These should be addressed by the corresponding 3rd party developers (Safari people, the Downloads window, do you really work at Apple???). And it seems there is API support for that.”

Safari’s Downloads window was what got me thinking about this whole problem in the first place. I downloaded a file in space 1, then closed the Downloads window. Then I opened a new Safari window and moved it to space 2. Then I downloaded another file and all of a sudden, Swoop! I’m back in space 1, where the Downloads window was last opened. That’s a prime example of how the current implementation of Spaces fails quite badly in certain situations.

But I think an important aspect of Spaces’ success is that it requires zero effort from application developers, including those inside Apple. It just works, and any modifications or improvements to Spaces need to maintain this arrangement. It’s not an easy task — something like building the Chunnel without having the French meet you halfway, or indeed without even talking to the French. Okay, it’s not THAT complex, but you get the idea. Developers shouldn’t have to mod their apps in any way for them to work out of the box in Spaces.

Still running Tiger (and VirtueDesktops) so I can’t test and answer this myself:

How does Spaces handle unsolicited popups (e.g. iChat requests) from an application that’s inactive or doesn’t have any open windows in the current space?

The rest of this post attempts to cover a few points as succinctly as possible (it’s challenging!) using examples from VirtueDesktops.

David said: With other pre-Leopard window managers, you didn’t get the auto-switching behavior.

Pretty sure that’s customizable (more or less) with most of those window managers. VirtueDesktops has a VirtueDesktops has a “Change desktop to show focused application” preference for controlling it. When enabled, a Command-Tab or Dock-click selection of an application will do a desktop switch. When disabled (my setting), the application becomes active in the current desktop. Finder does the latter, apparently ignoring the preference. One advantage to the pref being disabled being able to activate an application and open a new window for it on the current desktop, which apparently is only possible in Spaces be selecting “New Window” (?) from the app’s Dock menu. But it’s problematic in a way I’ll describe later.

There’s also a “Current Application: Don’t focus on desktop switch” option in per-window popup dialogs which I’d expect to override the global preference but in testing it seems to have no effect. In that dialog there’s also a “Current Window: Show window on all desktops” option, which I’ll set for my iChat message window (tabbed, with Chax) so it floats on each desktop. The iChat application options enable “Bind application to desktop Comm/PIM” so it’ll appear on that desktop when launched.

The problematic behavior I mentioned earlier has to do with creating new windows for applications that are bound to specific desktops. Using the iChat example, a request popup will appear on the current desktop but when that window is selected it jumps back to the Comm/PIM desktop that the app is bound to. Then I manually switch to Comm/PIM desktop and if I accept the chat I’ll set the “Current Window: Show window on all desktops” for that message window. Awkward but acceptable.

The key point is how my interest in having certain apps organized on specific desktops when initially *launched* conflicts with the ability to have their *future* windows appear/remain on arbitrary desktops. Spaces seems to be better about keeping windows where you leave them, while its auto-switching potentially interferes with explicitly selecting them.

That’s just one of many window manager usage scenarios to consider. It would take awhile to thoroughly analyze other combinations of application/window creation/selection/binding/closing situations that users of virtual window managers can encounter, but that’s what’ll be necessary to fully understand Space’s strengths and weaknesses… which hopefully leads to generally agreeable suggestions/solutions… that Apple will consider implementing. Looked at too narrowly and superficially an idea that would be great at solving one problem might negatively impact something else.

I appreciate Pascal’s suggestion (simple and generally effective, IMO) and the deeper discussion of Spaces issues it triggered. Thanks!

Pascal says: “Developers shouldn’t have to mod their apps in any way for them to work out of the box in Spaces.”

Agreed. But it makes me wonder:

Is it possible for Spaces to make/provide the kind of choices to minimize complex and frustrating usage scenarios without needing app-specific support? During the time I ran CodeTek VirtualDesktop Pro in pre-Tiger days I noticed quite a few changes related to making it behave “correctly” with specific apps. Will Spaces have to go through a similar process and/or will “impatient” apps be modified if Apple won’t do it (fast enough)?

@Pascal: I get the Channel analogy very well, being French myself. Impossible n’est pas français.

Regarding special windows in app, Apple did the best it could do by making Panel-type windows Space-independent. But the developers may have Panel-like windows that are not really Panel, from a programmatic point of view, and for different reasons (NSPanel class vs NSWindow class). Spaces cannot guess that the Documentation window of Xcode should follow the app through different Spaces, instead of triggering the Space dance.

In fact, the Panel vs Window analogy is very relevant. One of the reason the developer may choose a Panel vs a Window is that a Panel will by default be hidden when the app is not frontmost anymore. This is an example of where it is the developer responsibility to decide between different behaviour.

Hence, to some extent, some of the behavior has to rely on the developers’ hands, but here we are just talking about a more refined behaviour, and the app will work out of the box without this refinement.

wickedly good proposal for improving Spaces in Leopard. I love Spaces, but it’s got serious issues. This would be a painless solve for a large [...]

Excellent idea. I’m actually pretty happy with Spaces, though I think what you suggest here is too good not to do. I hope Apple hears you – I’ll be suggesting it to them: http://www.apple.com/feedback/macosx.html

Excellent, so true. It would be great if Apple implemented these features/updates. I have also been frustrated by Spaces. Maybe if Apple doesn’t do it, a third party might?

Yesohyesohyes… I would seriously want this feature. It’s the one reason I haven’t upgraded my Macbook to Leopard yet: it’s still running Virtue Desktop, which behaves just like I want

In an ideal world, what I’d like to see is a standard modifier combination that toggled the behaviour on the fly in all contexts. Call it fn. Then we could have

command-N -> new window in application space
fn-command-N -> new window in current space

click-in-Dock -> switch to app, move to space of frontmost window
fn-click-n-Dock -> switch to app, frontmost window to current space

Dock-select-window -> bring window frontmost, go to that space
fn-Dock-select-window -> bring window frontmost in current space

etc, etc, etc

It’s probably not entirely feasible because so many modifier combinations are already claimed but maybe it can be approximated.

[...] to make me considerably happier with Spaces behaviour. The first one has already been covered by Pascal.com. Include a ’switch spaces automatically’ checkbox, checked by default. Then make the [...]

@Pascal:
| Tom von Schwerdtner says: “The [Safari Download] window is just a utility, a notification
| really, why would you ever want to shift desktops just because of it?”

| 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.

Many good ideas
But I still like Apples way – so like you say it should be a extra option -
Right now Spaces has the good thing that if you have Safari in space 1 and fx. Mail in space 2, then you can “com (apple) click” on a link in a email if you want the new Safari window to open in the same space as Mail – thats nice – the only problem is that it opens in the background

Mark Barton says: “In an ideal world, what I’d like to see is a standard modifier combination that toggled the behaviour on the fly in all contexts. […] etc, etc, etc”

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.

Hey michael, you snuck in your post about command-click in Mail while I was still composing mine.

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.

[...] working as close to what I would have liked but still I would prefer if Apple were to fix Spaces as this post [...]

Yes, this would make Spaces useful. As it is, it’s spastic and annoying, despite its great potential and beautiful implementation.

Pascal, let me explain what I mean more thoroughly. I re-read your article closely (though still not all the comments), but I think I was confused by the paragraph starting “Let’s follow this through a bit more …” which seems to undermine the one above. At least it does to me. (I think you’re talking about certain child windows of certain apps, but it would probably be a bit difficult to empower Spaces to control a preference window of a particular app.) I take your point though about opening a new application window in my current space rather than switching which leads me on to say …

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.

[repost to fix botched blockquote; where's comment previewing when you need it?]

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.

Most Virtual Desktop apps for OS X have had these features for quite a while. CodeTek VirtualDesktop, Desktop Manager, VirtueDesktops and You Control: Desktops. Unfortunately, all of these apps seem to be discontinued with the exception of You Control’s Desktops. At $30, it might be pricey, but it’s worth the price to have control over your workspace.

I’d like to see an option to have a default space for apps to open in if you haven’t configured it to open somewhere specifically.

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.

[...] Not to mention that fact that the continued competition will hopefully serve as a prodding to Apple to bring added functionality and configurability to their own Spaces application within OS [...]

Having never used a Virtual Desktop program before, I’m finding Spaces excellent.

I agree (with so many others), this option would be great. Even a mere “defaults write”-solution would make me happy (though a setting is much more friendly of course). Reasonably, Spaces would still jump to apps bound to a specific space, but never otherwise (with this checked).

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..

I wish I had seen this article when I filed a Spaces bug report last week. Your suggestion is exactly mine. I received a reply saying that it was a “known issue” and that my bug report had been refiled under bug #4621420.

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.

This is an ancient post, but I’ll respond anyway. You can now do exactly this by changing a Dock default:

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