Bug report: Managed window doesn't snap into place when dragged over from one monitor to another

[lgug2z]

Bug report: Managed window doesn't snap into place when dragged over from one monitor to another

[LGUG2Z]

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]

@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:

swaywm_example.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]

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: #59 (comment)

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.