-
-
Notifications
You must be signed in to change notification settings - Fork 648
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changing focused space doesn't actually change focus #229
Comments
Because of lessons learned from its predecessors, yabai does never change window focus from window focused events. The flickering is a really bad experience. When switching spaces, macOS focuses the application that was most recently active on that space instead of a window on that space. As a workaround, you can focus the target window on the space before switching spaces. # instead of: yabai -m space --focus prev
yabai -m window --focus "$(yabai -m query --spaces --space prev | jq -r '."last-window"')" \
|| yabai -m space --focus prev
# instead of: yabai -m space --focus next
yabai -m window --focus "$(yabai -m query --spaces --space next | jq -r '."first-window"')" \
|| yabai -m space --focus next The space query attributes first-window / last-window hold the window ids of the first and last tiled window on that space. What's really missing here is a recent-window attribute for the most recently focused window on any space, and maybe the space focus command should default to focusing such a window if available. Edit:
|
This feels like something that should be considered a bug. Will take a closer look at this when I have time. |
So I tried to reproduce using the steps you've given. I'll re-list the steps here to make sure I did not misunderstand anything.
When I do the above, Kitty does become the active application and window for me, which is in line with what I expected with regards to how the code is written. The issue you are having is very likely because of the macOS most recently focused behaviour as described by @dominiklohmann I'm not sure I'd classify this as a bug, but I very much agree that this is an annoyance and it would be great if there was a clean way to solve this problem. As of now, a solution here will require further experimentation. |
Seems like I missed an earlier issue that seems to be very much the same as this one - see #160 |
Sorry I've not had time to do more digging. So, I thought I figured out the extra step that caused this... but I think I was wrong. Here was what I hoped would be correct:
And then it goes to the Chrome window on Display 1. This then makes sense with @dominiklohmann's explanation: when moving to the previous space on Display 2, the previously focused application on that display is Chrome, and there is a visible Chrome window (over on Display 1), so focus is sent there. Sadly, this didn't reproduce for me. But there is some sequence that triggers this. It keeps happening to me, about once or twice a day. I've yet to successfully retrace the sequence of steps though. I'll keep trying and update this bug if I succeed. That said, here are a bunch of thoughts I had about how to potentially overcome the issue Dominik explained (if in fact that is what I'm hitting and I've just not replicated the steps to hit it correctly..): One way would be to do what Dominik suggested and force focus a specific window on the target space rather than leaving it unspecified. However, there seems to be some bugs there. An option that would be nice (and close to Dominik's most recently focused window idea) is if you could query for the application most recently used on the space (the one macOS will target when moving to that space) and check if there are any windows from that application on the target space. If so, do what happens today. If not, pick the first window and focus that first before switching spaces. Another option which would work fine for me: when moving a window from one space to another, first de-focus that window in favor of any other window on its current space (the next one, the previous one, the first one all seem fine; you could even try to find a window from the same application to more closely replicate the macOS behavior when compatible). Then move the window to the new space and re-focus it after it moves. This will essentially ensure that the most-recently-focused application for any given space remains one with a window open in that space. When moving the last window out of a space, first focus the finder/desktop thing, and then move the window. Anyways, I'll see if I can stumble onto this and get a reproducer. Sorry for the noise so far. |
I tried to check for other issues, but they seemed different.
Reproduction steps:
yabai -m space --focus prev
via keyboardI would expect this to change the space on display #2 and focus on the only window in the new space (kitty in my case). Everything but the focus works (display #2 moves to the previous space where the kitty window is visible). However, it reliably sends the focus to the other still-visible Chrome window which is on display #1.
FWIW, Mojave, scripting extensions are enabled, and i'm using a homebrew install from head.
The text was updated successfully, but these errors were encountered: