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