-
Notifications
You must be signed in to change notification settings - Fork 11
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
[Bug] unable to focus window after movetonextdesk (ends up on wrong workspace) #57
Comments
hi! It looks to me that in the second console output the window was not moved at all...also it seems you have two instances of Rio, instead of 1? The fact that it is moved to workspace 6 instead of 5 is not important: if you have 3 monitors, by default on vdesk 2 there will be workspaces 4,5,6, and the window will just be placed wherever on one of these workspaces IIRC. Just wondering, does this happen if you move back and forth once between vdesk 1 and 2, before moving the window? |
To reproduce my issue I need 3 windows that stay on each of the 3 monitors on vdesk, one of them is a second rio window in the logs I provided.
I think it matters for me, there are different dispatchers to move windows around between visible monitors. I think the behavior of KDE or GNOME is what users would expect.
I have never tested this specifically. But also happened after using the vdesk 1 and 2 for some time, moving between them but leaving every window on the vdesk it was created on, and then moving a window from vdesk 1 to 2. the behavior is identical in that case.
This did not change anything. Thanks for investigating this. Tell me if I can help in any way. |
Misunderstood the logs, thought you also tried to move it back to first vdesk.
Yes, but this is not implemented in the plugin yet, so what you're seeing is not technically a bug, but a missing feature. So, given this, I think the actual bug in your situation is the artifacts, and the fact that the window cannot be focused. Do you use any software that manages monitors, like kanshi, shikane, way-displays or similar? These kind of problems are usually related to the fact that both Hyprland and the plugin are trying to move windows and workspaces around when monitors get connected/disconnected. I've been meaning to add a plugin event to avoid this to Hyprland, but never really got around to actually doing it |
Feel free to change this issue represent that.
No just hyprland and this plugin, with a static monitor configuration.
Thus I should open a separate feature request? |
Yes, you can open a feature request :) |
I also experienced same bug, for now I've set up permanent workspaces:
|
I really appreciate this plugin, thanks for the effort.
When I move windows between virtual desktops I'm unable to focus the moved windows and some artifacts appear on other monitors. After some time and jumping between desktops, I am once again able to focus the window, but on a different monitor without moving it there.
The simplest case I was able to reproduce consistently is with three monitors with one window each. Than I open a new window one of the monitors and move it via
movetonextdesk
.Further down is some console output that was captured while testing this.
For me it seems like the the window was moved to the wrong workspace (from 2 to 6 instead of from 2 to 5) and somehow the output of the workspace that the window landed on got displayed on the monitor the window came from.
Output of
hyprctl workspaces
&hyprctl clients
before runningmovetonextdesk
with window "Window 3ecf7e00 -> Rio" focusedafter
movetonextdesk
after moving back to desktop 1
The text was updated successfully, but these errors were encountered: