I’m running v2.2.6 on 10.9.4. I have the grid configured as a 4x4 with hotkeys configured to use a combination of modifier keys + arrow key to change space. (e.g. Control + arrow or Control & Command + arrow).
When holding down the modifier key and press the same arrow key more than twice (usually 3 times) to move from a space on one side of the grid to the other, it always performs the action as expected, but sporadically (about 25-33% of the time) within 1 or 2 seconds it will unexpectedly change spaces back in the opposite direction it had been travelling. Some times it will settle on that incorrect space other times it will change back to where it’s supposed to be all within a second. Then there is no other unexpected changes.
I can’t figure out other contributing factors to reliably cause this behaviour. I have changed modifier keys sequences and it does the same thing. This is the only problem I experience related to Spaces or TotalSpaces.
I’m not sure how to diagnose it further. Is there a way to trace / log actual space changes and perhaps the hotkey sequences to determine what is triggering the additional changes?
I sometimes see this behaviour. It is due to the system activating the apps on a particular space as you pass by that space. If the app is slow to respond, it can demand attention and cause an additional space switch to the space it is on.
It’s pretty hard to reliably filter these spurious switches, because usually we do need to pay attention when the system demands a space switch (for instance when you click on an app in the Dock or use cmd-tab).
Is it worse in 2.2.6 than earlier?
One minor change in 2.2.6 attempted to not activate a desktop if you are just passing by. But this depends on there being a space switch queued - if your space switching is set to be very fast (or transitions are turned off) then you will not see the benefit of this change.
Thanks for the reply. Your description fits what I’m seeing. The behaviour and regularity of it could be the apps I have on the various screens and how bogged down the system is. (This is a 2010 iMac 16GB rotating disk which does tend to get bogged down the browser a bit).
I run with transitions turned off. I sure I’ve had them turned off for quite a while as this gives me the most responsive window changes.
I can’t be sure on this, but I think it does feel worse in recent versions, but the problem is that it maybe system load, window config and my sensitivity to it that makes me think it’s worse.
Are you able to prevent the involuntary switches / not activate a desktop - if so, what about not activating the desktop when the modifier key is still held down or for a second or so after totalspaces initiates a move. (I’m not sure what control you have over preventing it. It was what you’d said about filtering them and the 2.2.6 change). I’m not sure if it’s a setting, but I don’t switch spaces when clicking on an app in the dock or doing command tab, and I like it like this. I don’t mind it changing focus to a different app, but I wouldn’t want it changing spaces on me just because I activated a different app. (In System Preferences -> Mission Control: I have “When switching to an application…” unset.)
I am considering what can be done for this - in your case it seems like we could implement a work around.
Hi, I’m having the exact same problem as obscurebug. Same settings in mission control, but on a 2010 MacBook Pro with an SSD. (It’s still pretty slow.)
I don’t believe that I had this problem when I first got TotalSpaces2 in April. However this could be due to changes in my system rather than due to patches of TotalSpaces2.
I would really like to see a solution to this problem.
Actually, on further inspection perhaps my case is different. Mine doesn’t always backtrack to a previous workspace, but will sometimes make additional seemingly random moves.
For instance, in my 3x3 workspace grid I just pressed up twice, and got the behaviour for up, up, right. So the explanation you gave may not be correct. Additionally, like obscurebug, I have disabled the setting that forces a workspace change on focus.
I have been looking at this. I can reproduce the issue (at least with the switch back), and I see system generated space changes that are hard to filter.
Probably the best I can do is to filter them within a short time limit of the most recent commanded change. It’ll be a bit trial and error to get the right timeout - I’ll try to get a pre-release app for you to test soon.
BTW, as you may guess I have looked at this problem before, and it’s always been present to some extent. But although mostly these days people don’t experience it if they use transitions. I’ve always wanted to find a better solution.