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.
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
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.
@posburn I have loaded the context of this problem to my head again.
Here are implementation notes:
Visor implements auto-slide feature. It means when Finder.app 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), Finder.app gets activated by the system.
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?
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
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!
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):
DISPLAY1-SPACE1 has Safari (keyboard focus)
you trigger keyboard shortcut to display visor on DISPLAY2-SPACE3 => system switches active space to SPACE3, but keeps Safari as an active app
at this point I remember Safari as the last active PID for SPACE3
later system transfers focus to Visor window
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!
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.
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.
