Focus state lost if no windows on display

[brianwk]

Despite the mouse being in the external display, the focus will be determined to still be on the built-in display if my space is empty. This causes the hotkeys to cycle through the spaces of the other display instead of the one with the cursor active on it. If I then activate one window on the other display, I can finally become "unstuck" from that empty workspace.

I think this may be the cause of a few issues. The only workaround I found is to activate an application on the display. This sometimes causes the windows to deactivate on the other display.

[brianwk]

Steps to reproduce:

• Open Finder or Notes app in a space by itself. The app window will eventually become "Deactivated" and lost. The same issue occurs in Aerospace. I have these windows set as Floating windows in my config.
• Once the app window is "lost" as described above, skipping the empty workspace will no longer work. I think rift is waiting for one of these windows to have focus which never happens.
• You will now be stuck on that empty space on the display. If you click on any app running on a virtual space in that display / MacOS space everything will return to normal.

Maybe the cause is "ghost windows"?

[brianwk]

If you go to a empty space on a display, use the mouse to go back to the other display, and then attempt to use ALT+H to go left nothing happens. Also on the display with the empty space there is no way to navigate to another space. You simply become stuck on that empty space until you activate an application using the Dock for example.

I realized that this issue may be a duplicate of #97 after further review.

[brianwk]

I'm actually experiencing this issue regardless of what display has an empty space on it. Also if you use the shortcuts like ALT+H and go to an empty workspace, you will be stuck on that workspace on that display after it wraps to the next display.

Also just to be clear if you are on a single monitor you won't experience this, since the core of the issue is that the focus doesn't follow the mouse to the next display / MacOS space.

I think the solution is to use the same event as https://www.hammerspoon.org/docs/hs.screen.watcher.html#newWithActiveScreen to determine the "main screen"
edit: I tried to add a listener using ns_string! for the private event from Hammerspoon, but it doesn't seem to work and I gave up.

[acsandmann]

@brianwk does the latest commit help things?

[brianwk]

@acsandmann i'm no longer at the office so I won't be able to test this until tomorrow morning with an extra display.

[pyinto]

@brianwk also gonna drop it here, might make testing less of a hustle for you guys:

When no external display available you can emulate it:
I personally use BetterDisplay for that (not its primary function), but it's behind a paywall (free trial is available).
Here is another, free one: https://github.com/Stengo/DeskPad

[brianwk]

@acsandmann I'll in the office soon and I'll let you know.

[brianwk]

@acsandmann not fixed. the only thing that is fixed is that when i go to the next screen and I do ALT+S (thats the hotkey I set for next workspace) it no longer will run the command on the wrong display. However, I'm still stuck on the empty space. Also if I do a command to switch the workspace to a specific one then it will change the workspace on the wrong display.

edit: I just updated to the latest main branch as of right now. The ALT+S hotkey to go to next space works, but when I switch monitors using the cursor the command no longer does anything until I go back to the original monitor rift was running on.

Double edit: I switch to a specific workspace it works on both displays. We are so close!