mirror of
https://github.com/LGUG2Z/komorebi.git
synced 2026-01-11 14:40:25 +01:00
Bug report: Managed window doesn't snap into place when dragged over from one monitor to another #50
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @da-rth on GitHub (Oct 29, 2021).
Originally assigned to: @LGUG2Z on GitHub.
Issue:
Dagging a managed window onto an empty desktop on a different monitor will result in the window remaining in floating state above over the desktop of the different monitor, instead of snapping into place and being managed by the workspace of the monitor.
Expected behaviour:
Dragging a .managed window from one monitor to another should result in the window being managed and snapping into place on the destination monitor.
Steps to reproduce:
@LGUG2Z commented on GitHub (Oct 29, 2021):
The behaviour when dragging a window container onto an empty monitor workspace is clear for me; it should be appended to that (empty) workspace.
I'm not sure what the defeat behaviour should be when dragging to another monitor with an already populated workspace. Should the window being dragged be swapped with the window it ends up over (ie. across monitors)? Or should the window just be appended (or prepended) to the focused workspace of the target monitor?
Open to suggestions for defining the default behaviour.
@da-rth commented on GitHub (Oct 29, 2021):
@LGUG2Z we could define behaviour similar to that of SwayWM:
dragging a (source) window onto the left or right side of another (destination) window will split the destination window, placing the source window tiled to the left or right of the destination window
dragging a source window into the center area of another destination window will swap that window with the source window
SwayWM actually displays a coloured rectangle guide above the destination window (where the source window is being dragged to) in order to show which action will be taken:
https://user-images.githubusercontent.com/10499053/139392974-36ac0375-4c06-4023-8f0c-d145c61179fe.mp4
So when dragging over a window, you would split the destination window into 5 sections and decide the action based on which section the cursor lands in when releasing the mouse:
I do think a visual rectangle guide would be very useful if this were to be implemented
@LGUG2Z commented on GitHub (Oct 29, 2021):
The way that Sway handles this is very elegant. I think being able to do this also depends to some extend on what I mentioned in this issue, in order to be able to resolve sibling nodes, parent nodes and child nodes quickly and easily for any layout: https://github.com/LGUG2Z/komorebi/issues/59#issuecomment-954837951
In order to have this case handled in a minimal way until then, when dragging a window between monitors to a destination monitor that already contains 1+ visible window containers, I will have the source window container inserted at the index of the window container the mouse drags ends on the destination monitor/workspace.
For the Sway-like zones, let's create a new issue from your comment that can be tracked as a feature request.