Skip to content
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

Closed
BlueDrink9 opened this issue Apr 1, 2020 · 8 comments
Closed

New windows don't open on focused display #467

BlueDrink9 opened this issue Apr 1, 2020 · 8 comments
Labels
suggestion Request for new feature or some form of enhancement

Comments

@BlueDrink9
Copy link

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!)

@koekeishiya
Copy link
Owner

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.

@koekeishiya koekeishiya added the suggestion Request for new feature or some form of enhancement label Apr 1, 2020
@dominiklohmann
Copy link
Collaborator

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).

@koekeishiya
Copy link
Owner

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.

@BlueDrink9
Copy link
Author

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.

@koekeishiya
Copy link
Owner

koekeishiya commented Jun 5, 2020

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.

@BlueDrink9
Copy link
Author

Sounds like a reasonable approach. Will probably reduce issues with pop-up windows opening on unfocussed spaces and being moved to the current one

koekeishiya added a commit that referenced this issue Jun 6, 2020
…ed display instead of the display it spawned at
@koekeishiya
Copy link
Owner

koekeishiya commented Jun 6, 2020

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.

@koekeishiya koekeishiya added the addressed on master; not released Fixed upstream, but not yet released label Jun 6, 2020
@aiguofer
Copy link

aiguofer commented Jun 6, 2020

👏 this has been bothering me for awhile... looking forward to it! thanks for all your hard work :)

@koekeishiya koekeishiya removed the addressed on master; not released Fixed upstream, but not yet released label Jun 8, 2020
unrevre pushed a commit to unrevre/yabai that referenced this issue Jan 26, 2022
…n the focused display instead of the display it spawned at
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
suggestion Request for new feature or some form of enhancement
Projects
None yet
Development

No branches or pull requests

4 participants