Expected behavior
The window's movement trajectory of the move-to-monitor command is not repeated.
Operating System
OS 名称: Microsoft Windows 11 家庭中文版
OS 版本: 10.0.22631 暂缺 Build 22631
Originally created by @MasouShizuka on GitHub (Jul 12, 2024).
**Describe the bug**
When using the `move-to-monitor` command, the window's movement trajectory will repeat, as follows:
https://github.com/user-attachments/assets/95f4421a-4660-4215-a194-4fd93dfedffc
However, when using the `send-to-monitor` command, the window's motion trajectory is normal, as shown below:
https://github.com/user-attachments/assets/726a2165-07b1-4f8c-b856-f78ee506d205
**To Reproduce**
Steps to reproduce the behavior:
1. Just use these two commands separately
**Expected behavior**
The window's movement trajectory of the `move-to-monitor` command is not repeated.
**Operating System**
```
OS 名称: Microsoft Windows 11 家庭中文版
OS 版本: 10.0.22631 暂缺 Build 22631
```
adam
added the bug label 2026-01-05 14:50:42 +01:00
Similar issues have been reported generally with cross-monitor moves. I think the best way forward here for now is to disable animations in general for any operations that move windows across monitor or workspace boundaries.
@LGUG2Z commented on GitHub (Jul 12, 2024):
Similar issues have been reported generally with cross-monitor moves. I think the best way forward here for now is to disable animations in general for any operations that move windows across monitor or workspace boundaries.
This fix is not appropriate.
If the intermediate code encounters a ? and throws an error, ANIMATION_ENABLED will not be restored to its original value.
@MasouShizuka commented on GitHub (Jul 12, 2024):
This fix is not appropriate.
If the intermediate code encounters a `?` and throws an error, `ANIMATION_ENABLED` will not be restored to its original value.
This ensures that the value set for animation in the configuration will always be eventually consistent even if there are sporadic intermittent errors (subsequent successful calls that manipulate ANIMATION_TEMPORARILY_DISABLED will reset the value to false).
@LGUG2Z commented on GitHub (Jul 12, 2024):
Updated the commit to follow the same pattern as when we temporarily disable borders: https://github.com/LGUG2Z/komorebi/blob/50a279239a640e0ba0f4a3778e3ea99e65bb2238/komorebi/src/border_manager/mod.rs#L40
This ensures that the value set for `animation` in the configuration will always be eventually consistent even if there are sporadic intermittent errors (subsequent successful calls that manipulate `ANIMATION_TEMPORARILY_DISABLED` will reset the value to false).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @MasouShizuka on GitHub (Jul 12, 2024).
Describe the bug
When using the
move-to-monitorcommand, the window's movement trajectory will repeat, as follows:https://github.com/user-attachments/assets/95f4421a-4660-4215-a194-4fd93dfedffc
However, when using the
send-to-monitorcommand, the window's motion trajectory is normal, as shown below:https://github.com/user-attachments/assets/726a2165-07b1-4f8c-b856-f78ee506d205
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The window's movement trajectory of the
move-to-monitorcommand is not repeated.Operating System
@LGUG2Z commented on GitHub (Jul 12, 2024):
Similar issues have been reported generally with cross-monitor moves. I think the best way forward here for now is to disable animations in general for any operations that move windows across monitor or workspace boundaries.
@MasouShizuka commented on GitHub (Jul 12, 2024):
This fix is not appropriate.
If the intermediate code encounters a
?and throws an error,ANIMATION_ENABLEDwill not be restored to its original value.@LGUG2Z commented on GitHub (Jul 12, 2024):
Updated the commit to follow the same pattern as when we temporarily disable borders: https://github.com/LGUG2Z/komorebi/blob/50a279239a640e0ba0f4a3778e3ea99e65bb2238/komorebi/src/border_manager/mod.rs#L40
This ensures that the value set for
animationin the configuration will always be eventually consistent even if there are sporadic intermittent errors (subsequent successful calls that manipulateANIMATION_TEMPORARILY_DISABLEDwill reset the value to false).