Skip to content

Windows don't always open on the display that the mouse cursor is on #1228

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

Closed
leviport opened this issue Oct 26, 2021 Discussed in #1225 · 7 comments
Closed

Windows don't always open on the display that the mouse cursor is on #1228

leviport opened this issue Oct 26, 2021 Discussed in #1225 · 7 comments

Comments

@leviport
Copy link
Member

As shown in the video in the discussion post, new windows will open up on the wrong display if I have an active window on a display, and the display with my mouse cursor is empty.

Additionally, if I have windows open on multiple displays, and I move my mouse cursor to a display that doesn't have active windows (focus-on-hover must be turned off for this to work) then open a new window, the new window will fork from the active window on a display that my mouse cursor is not on.

Discussed in #1225

Originally posted by leviport October 25, 2021
When in tiling mode, new windows used to open on the display that the mouse cursor was on. This behavior was changed with 49aba22 so that new windows always branch from the currently active window, no matter which display the mouse cursor is on.

This can lead to some jarring behavior like windows appearing on a different display from the dock or launcher they were launched from, as shown in the recording below:

simplescreenrecorder-2021-10-25_15.15.45.mp4

I am having a hard time deciding whether the old way or the new way makes the most sense, so here's my idea: what if we made it a setting? I think the options could be something along the lines of, "New windows branch from active window" or "New windows follow mouse".

@mmstick
Copy link
Member

mmstick commented Oct 26, 2021

I think this is already fixed in the master branch.

@mmstick
Copy link
Member

mmstick commented Oct 26, 2021

I will release the updates in staging.

@jacobgkau
Copy link
Member

jacobgkau commented Oct 26, 2021

6421fff - Is this the commit that would have fixed it? It looks like this was committed straight to master. Was this made in relation to a PR or issue?

@mmstick
Copy link
Member

mmstick commented Oct 26, 2021

Yes, it's a revert of the commit that makes windows ignore the display that they are on, as discussed in #1213, which does the same thing.

@jacobgkau
Copy link
Member

jacobgkau commented Oct 26, 2021

#1213 isn't approved or merged yet, and nothing in the discussion there indicates that was already done.

@ehardesty
Copy link

This appears to be fixed for me in Manjaro which is up to date to commit 1fddaa8

@jacobgkau
Copy link
Member

Yes, this was fixed in 6421fff.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants