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
I hope I will revisit this issue later…
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.
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.
I understand. Will look at it tomorrow.
@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.
You can disable this behaviour from Terminal:
defaults write com.apple.finder TotalFinderDontAutoSlideVisor -bool YES
- 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!
@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):
- 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!
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.
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.
Also, I am still getting the occasional unwanted Visor pop-up when I switch to a space with no open apps. This is after I input the boolean value you suggested above.
I will sit on it tomorrow and test it again. This sucks.
@posburn Finally, I took some time to revisit this again. I tested my debug build as well as TF release 1.5.9 under 10.9.2 with and without latest TS and my fix is effective. I’m no longer able to reproduce your behaviour in post 17.
Are you really sure you were testing the latest version?
btw. this is my mission control settings:
Any additional insights?
I’m considering sending you a debug build to see what will be reported in the debug console.
Hmm. Now I’m really confused. I am, in fact, using TF 1.5.9, from a fresh install (I uninstalled the older version first). My Mission Control settings aren’t that different from yours; “Displays have separate Spaces” is unchecked, the hotkeys are different.
I created a new user, logged in as that user, and I was not able to reproduce the problem by following the steps in post 17. No unwanted space switching, no unwanted sliding of Visor when I switched to an empty Space. Does this perhaps point to some system cruft or a corrupted plist file from a previous install? I did click the “Reset TotalFinder to Defaults” button under “About” in the prefs, but this did not fix anything. Perhaps a manual delete of the plist?
Or maybe there are some other apps I have running that could conflict with TF (Hyperdock, Hyperswitch, BetterTouchTool, Alfred 2, PopClip, etc.)? I tried disabling each of these apps, but there was no difference. I certainly could have missed something.
Any suggestions? I would also be happy to try a debug build and send you the output.
Sorry for all the frustration!
@darwin, I think I have solved my problem! On a whim, I decided to check the “Displays have separate Spaces” box in the Mission Control prefs. I logged out and back in and the problems seem to have disappeared! Seems odd that this would fix the issue, but it looks like that’s the story. I’ll let you know if it happens again.
I guess the test user I created worked okay because “Displays have separate Spaces” is the default setting. I had turned it off because I use my MBP for teaching presentations daily and it seems like the default setting caused me some issues. I’ll have to see if those other issues pop up again.
Thanks so much for all your help and patience!
Update: I do still occasionally get unwanted Visor pop-up when I switch to an empty space (despite the DontAutoSlideVisor boolean being checked in the plist file). Unfortunately, I can’t seem to find any rhyme or reason to this; it doesn’t happen every time, and there doesn’t appear to be any pattern. However, I think I can live with these Visor auto-slides.
I have not had any unwanted space switches, though! This is really the bigger deal in my opinion, so I’m happy.