Allow dragging tiled windows with the mouse. (#3085)

Fixes #2643

Inner drop region behaves like move to mark.
The outer region is close to the edge (currently 30px from the edge).
This will place the container as a sibling in the given direction within
the parent container. If the move direction goes against the orientation
of the parent container, tree_move() is called.

Contributors:
Co-authored-by: Orestis Floros <orestisflo@gmail.com>
See #3085
- Inner drop region behaves like move to mark
- Handle workspaces
- Fix crash when target closes
- Initiate tiling drag from titlebar
- Hide indicator until container is dragged outside of original position
- Calculate outer_threshold using percentages instead of fixed pixel
values
- Emit 'move' event properly
- Don't focus previously unfocused containers
- Use tree_split() on different orientation
- Fix redundant split containers
- DT_PARENT
- Readability & optimizations
- Limit parent threshold by render_deco_height()
- Tests
- Fullscreen container handling
- Initiate drag from title bar
- Fix issue of EnterNotify events still triggering after drag_callback
  is called
- Include decorations for drop target calculation

Co-authored-by: Michael Forster <email@michael-forster.de>
See #2178
- Original implementation of tiling drag + indicator window
> A container can be dragged by the title bar to one of the four sides
> of another container. That container will then be split either
> horizontally or vertically.

Co-authored-by: Tony Crisci <tony@dubstepdish.com>
See #2653
- Original implementation of outer/inner drop region indicator:
> There are two drop regions per direction.
>
> The inner region is closer to the center of the window. Dropping on
> this region will split the target container and put the container
> within the split at the given direction beside the target container.
>
> The outer region is close to the edge (currently 30px from the edge).
> This will place the container as a sibling in the given direction within
> the parent container.
>
> Dropping into the outer region moves the con beside the target. If the
> move direction goes against the orientation of the parent container, the
> con moves out of the row.
- Fix crash: Ignore containers without a managed window (eg i3bar)

1 files changed, 45 insertions, 0 deletions

diff --git a/docs/userguide b/docs/userguide
index e7ec29d6..7b233844 100644
--- a/docs/userguide
+++ b/docs/userguide
@@ -196,6 +196,48 @@ provided by the i3 https://github.com/i3/i3/blob/next/etc/config.keycodes[defaul
 
 Floating windows are always on top of tiling windows.
 
+=== Moving tiling containers with the mouse
+
+Since i3 4.21, it's possible to drag tiling containers using the mouse. The
+drag can be initiated either by dragging the window's titlebar or by pressing
+the <<floating_modifier>> and dragging the container while holding the
+left-click button.
+
+Once the drag is initiated and the cursor has left the original container, drop
+indicators are created according to the position of the cursor relatively to
+the target container. These indicators help you understand what the resulting
+<<tree>> layout is going to be after you release the mouse button.
+
+The possible drop positions are:
+
+Drop on container::
+    This happens when the mouse is relatively near the center of a container.
+    If the mouse is released, the result is exactly as if you had run the
+    +move container to mark+ command. See <<move_to_mark>>.
+Drop as sibling::
+    This happens when the mouse is relatively near the edge of a container. If
+    the mouse is released, the dragged container will become a sibling of the
+    target container, placed left/right/up/down according to the position of
+    the indicator.
+    This might or might not create a new v-split or h-split according to the
+    previous layout of the target container. For example, if the target
+    container is in an h-split and you drop the dragged container below it, the
+    new layout will have to be a v-split.
+Drop to parent::
+    This happens when the mouse is relatively near the edge of a container (but
+    even closer to the border in comparison to the sibling case above) *and* if
+    that edge is also the parent container's edge. For example, if three
+    containers are in a horizontal layout then edges where this can happen is
+    the left edge of the left container, the right edge of the right container
+    and all bottom and top edges of all three containers.
+    If the mouse is released, the container is first dropped as a sibling to
+    the target container, like in the case above, and then is moved
+    directionally like with the +move left|right|down|up+ command. See
+    <<move_direction>>.
+
+The color of the indicator matches the +client.focused+ setting. See <<client_colors>>.
+
+[[tree]]
 == Tree
 
 i3 stores all information about the X11 outputs, workspaces and layout of the
@@ -1041,6 +1083,7 @@ workspace 5 output VGA1 LVDS1
 workspace "2: vim" output VGA1
 ---------------------------
 
+[[client_colors]]
 === Changing colors
 
 You can change all colors which i3 uses to draw the window decorations.
@@ -2253,6 +2296,7 @@ Note that you might not have a primary output configured yet. To do so, run:
 xrandr --output <output> --primary
 -------------------------
 
+[[move_direction]]
 === Moving containers
 
 Use the +move+ command to move a container.
@@ -2537,6 +2581,7 @@ Note that you might not have a primary output configured yet. To do so, run:
 xrandr --output <output> --primary
 -------------------------
 
+[[move_to_mark]]
 === Moving containers/windows to marks
 
 To move a container to another container with a specific mark (see <<vim_like_marks>>),