-
-
Notifications
You must be signed in to change notification settings - Fork 661
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
New windows don't open on focused display #467
Comments
Hmm I suggested something similar in #459 (comment) I suppose what you refer to as the focused space/display could differ from the cursor display, so maybe the proposed solution would have to be able to select one out of multiple alternatives. |
Related thought: More generally this could also be implemented by adding a way to run signals synchronously before even rules are run (and thus before windows are tiled). |
I agree that would open the door to a bunch of new possibilities, but it would more or less require rethinking the whole event structure. For some events there would be mandatory work that has to happen before a signal could intercept it, and for other events that wouldn't be a thing. |
Spawning on cursor space would definitely be better, because there's a higher chance that the cursor is on the correct screen than the incorrect one. Also, mouse-follows-focus would keep in consistent if working fully with the keyboard. |
Is there even really a reason why this should not be the default behaviour? Edit: I guess the only reason is my previous stance of not trying to mess around and override macOS default behaviour, because it can easily create an inconsistent experience. Maybe a compromise here would be that we only move the window to the focused display if the window is going to be managed by yabai, aka it is going to be tiled. All floating windows would be left untouched. |
Sounds like a reasonable approach. Will probably reduce issues with pop-up windows opening on unfocussed spaces and being moved to the current one |
…ed display instead of the display it spawned at
Implemented on master. I think this is reasonable default behaviour and therefore there is not a config setting to opt in/out of this. I do feel like this is the more intuitive way for things to work, and I have to admit it has been bugging me a lot lately, where I launch an application and then have to manually move it because it spawned at the wrong display. |
👏 this has been bothering me for awhile... looking forward to it! thanks for all your hard work :) |
…n the focused display instead of the display it spawned at
I think this is more of an OSX issue, but I was wondering if using Yabai allowed some sort of workaround.
Currently, if I open a terminal window on one display, then focus another display and open another terminal window, the second window opens on the first display.
I want windows to open on whatever space/display I currently have focused.
This also happens with finder and chrome (only ones I tested on), which is why I think it differs from #413.
Any thoughts?
(I've just switched from Chunkwm and I have to thank you once again for your amazing work. Configuring skhd is much tidier now too!)
The text was updated successfully, but these errors were encountered: