You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently when using the mouse to move windows, komorebi only checks to start a move operation if the origin workspace is tiling and it checks for the focused container so if we move floating_windows or if we move a window from a floating workspace the MoveResizeStart event won't create a pending move operation or it will create a wrong one (in the case of floating_windows).
Then moving this windows back can create problems.
In the case of the floating_windows nothing bad seems to happen and it is all ignored, although the window never gets transferred to the other monitor on komorebi as it should...
The worst thing is when moving from a floating layout since that won't create a pending move, the window won't be transferred however when moving back, since now the origin workspace will be tiling it will create the pending operation but with the focused container which will be the container that already existed before on that workspace, which results on komorebi transferring that window to the other monitor, however this only happens on komorebi since the target workspace is now a floating workspace it's update function won't move the window from the other monitor and it stays there looking like it is were it was before but unmanaged, when in fact it is now owned by the floating workspace and the only way to fix it is to manually move it with mouse to the floating workspace and then use a keybind/command to move it to the tiling workspace again...
Version Information
This happens on 0.1.29 and even on master...
Komorebi Configuration
(Can I leave this emtpy?! :P )
Hotkey Configuration
(Can I leave this emtpy?! 😅)
Output of komorebic check
(Can I leave this emtpy?! 😅)
The text was updated successfully, but these errors were encountered:
This issue was first brought up on this discord support thread.
Another related issue was found there where using the move-window commands to a direction where it ends up moving them to another monitor or workspace also misbehaves if the target workspace is not tiling (floating mode). I'll have this one on a different PR.
I'm adding this comment here so I don't forget about this later... 😅 @LGUG2Z If you want me to instead open another issue for this one, I can do so...
Summary
Currently when using the mouse to move windows, komorebi only checks to start a move operation if the origin workspace is tiling and it checks for the focused container so if we move
floating_windows
or if we move a window from a floating workspace theMoveResizeStart
event won't create a pending move operation or it will create a wrong one (in the case offloating_windows
).Then moving this windows back can create problems.
In the case of the
floating_windows
nothing bad seems to happen and it is all ignored, although the window never gets transferred to the other monitor on komorebi as it should...The worst thing is when moving from a floating layout since that won't create a pending move, the window won't be transferred however when moving back, since now the origin workspace will be tiling it will create the pending operation but with the focused container which will be the container that already existed before on that workspace, which results on komorebi transferring that window to the other monitor, however this only happens on komorebi since the target workspace is now a floating workspace it's update function won't move the window from the other monitor and it stays there looking like it is were it was before but unmanaged, when in fact it is now owned by the floating workspace and the only way to fix it is to manually move it with mouse to the floating workspace and then use a keybind/command to move it to the tiling workspace again...
Version Information
This happens on 0.1.29 and even on master...
Komorebi Configuration
(Can I leave this emtpy?! :P )
Hotkey Configuration
(Can I leave this emtpy?! 😅)
Output of komorebic check
(Can I leave this emtpy?! 😅)
The text was updated successfully, but these errors were encountered: