TF can sometimes force an unwanted space switch

I’ve noticed (and mentioned on old forums, I think) that TF has a mildly annoying tendency to force an unwanted space switch.

Steps to reproduce: (example apps and spaces used, AFAIK this will occur for any app on any space):

(1) Be working in some window, say Safari (like I am now) on Desktop 1

(2) Summon Visor on Desktop 1 using hotkey (CTRL + ` for me)

(3) Switch to Desktop 2 using hotkey (ALT + 2 for me)

(4) is now the “active” app on Desktop 2; the Visor is behind it

(5) Bring Visor to front w/ hotkey

(6) Dismiss Visor w/ same hotkey

(7) Get magically transported back to Desktop 1, with Safari now as the active app :frowning:

Desired behavior: in (7), I should stay on Desktop 2 with Mail as the active app :slight_smile:

Any suggestions? Or is there some OS X goofery going on that cannot be addressed by TF?

Has no one else observed this? If it’s just me, I’d appreciate some suggestion on how to make it stop.

I noticed, and it is really annoying. Not sure how to fix. Any suggestion people?

I will look into that. I think TotalFinder will need similar fixes as I implemented in TotalTerminal’s Visor.

This is not only Visor. Any time, when a TF window is opened and active, switch to another space, then click somewhere (for example on Notes on Dashboard), it is switching back to previous space.

Do we have any updates on that?

I’m going to investigate it right now.

I was able to reproduce @posburn’s case with pinned visor. This will be fixed in next version.

Avik’s issue is something different. I was able to reproduce it and looking for solution.

@Avik_Aghajanyan’s issue was introduced by my fix of this issue in 1.4.9:

I have to find a better solution.

Fantastic! Thanks very much, Antonin!

Thanks Darwin! Much Appreciated. Waiting for update

Unfortunately @Avik_Aghajanyan issue won’t be resolved in the next release. I haven’t found good solution and it is pretty hard to detect that active space is Dashboard to do some workaround :frowning:

I hope I will revisit this issue later…

Hi @darwin,

The problem I mentioned in this thread has returned in TF 1.5.2, on Mavericks: dismissing Visor sometimes causes a space switch. Similarly, switching to an empty (no open apps) space will sometimes summon Visor unintentionally.

I know you guys are probably inundated with support requests, so no rush. Just thought I’d make a note of it. :smiley:

1 Like

Any progress on this? I was hoping maybe this would be fixed in TF 1.5.6, but no dice. It’s officially driving me crazy now. :smile:

I understand. Will look at it tomorrow.

@posburn I have loaded the context of this problem to my head again.

Here are implementation notes:

  1. Visor implements auto-slide feature. It means when gets activated by the system and Visor window is the only TotalFinder window, I slide it up.

Unfortunately system behaviour is that if you switch to an empty space (space with no apps running in it), gets activated by the system.

You can disable this behaviour from Terminal:

defaults write TotalFinderDontAutoSlideVisor -bool YES
  1. Problem described in your original post should be fixed. Original implementation just remembered previous app prior Visor activation and returned keyboard focus to it after Visor closure.

New implementation does also background checking on timer. It remembers last active non-finder app during Visor session. Imagine you were in app1, you activated and pinned the Visor, switched to some other app2, returned to Visor and then dismissed it. Old implementation would simply return to app1. New implementation should return to app2. If this does not work in some subtle cases, I have probably a bug in the implementation.

I would like to hear more details about “dismissing Visor sometimes causes a space switch”. Can you help me reproduce it reliably?

Hi @darwin,

Thanks very much for looking at this. The boolean you suggested does appear to address the Visor auto-popup when switching to a blank space.

Here are the (example) steps to reproduce the second problem:

(1) Start on Space 1; Safari is the active app
(2) Summon Visor with keystroke; Finder is now the active app
(3) Switch to another space (e.g., Space 2). There is no other open app here, so Finder (Visor) becomes the active app.
(4) Dismiss Visor via keystroke
(5) Teleport back to Space 1 :smile:

I recognize now that this problem is a bit different than the one I first reported in that I am switching to an empty space in step 3.

Here’s a QT screencast (poor qual, I know) of this behavior. Let me know if there’s any other info I can provide!

@posburn Thank you for detailed description.

I believe I have fixed/improved focus restoration in 1.5.8 (will be released soon). It should fix your use case (I tested it both under Mountain Lion and Mavericks).

FYI. The new implementation tracks previous app PID per space. This means that when you have focused Safari on SPACE1 (so SPACE1’s last PID is Safari), then moved to SPACE2 (SPACES2’s last PID is nothing) and dismissed visor on SPACE2 => it looks into SPACE2’s last PID which is nothing and that means no keyboard focus restoration, and that means no unwanted space switch.

Imagine a slightly modified case when you have focused Safari on SPACE1 (so SPACE1’s last PID is Safari), then moved to SPACE2 (SPACES2’s last PID is nothing), then moved back to SPACE1 and dismissed visor. In this case it will return focus back to Safari, because at the point of dismissing visor, keyboard restoration code looks for last active PID on SPACE1 which is Safari.

This new code should also play well with Mavericks multi-display situation (where you have individual spaces-set per desktop). In theory it should not work across displays, because each display has different space.
But it works as expected, because here I depend on timing of system operations. OS first switches active space and later it transfers keyboard focus. This allows me to remember PID of previous app and assign it to target space.

Example (two displays each with two spaces):

  1. DISPLAY1-SPACE1 has Safari (keyboard focus)
  2. you trigger keyboard shortcut to display visor on DISPLAY2-SPACE3 => system switches active space to SPACE3, but keeps Safari as an active app
  3. at this point I remember Safari as the last active PID for SPACE3
  4. later system transfers focus to Visor window
  5. when you dismiss visor window (on SPACE3), it will correctly return focus to Safari (although it will lead to focusing window on a different space)

I tested also scenarios with pinned visor and switching between apps on different displays and spaces. All looked good. No unwanted space switches even in complex scenarios.

@darwin Thanks so much for taking to time to look at this, and for taking the time for such a detailed response. Time after time, BinaryAge has proven that they care very much about their users, making it a real pleasure to use your software. I look forward to TF 1.5.8!


1 Like

Hi, Antonin (@darwin):

I am sorry to report that the problem I noted in post 17 is still present in TF 1.5.9. I can follow the exact steps in post 17 to reproduce. :frowning:

If it helps, I am only using one display, an external monitor connected to my MBP. I am using TS 2.0.11 with 9 desktops (not sure if that’s relevant). Please let me know if there’s any other information I can provide.

Also, in the process of playing around with various settings to see if I could discover any patterns with this problem, I noticed that if I right click on the TF dock icon and set Options > Assign To > None OR Assign To > This Desktop, then the desktop icons disappear from all spaces except the space I was last on when I made this selection. This is a bit strange.