Description
I just switched to sway from i3 and noticed an inconsistency in what is a fairly common workflow for me.
I'm using sway version 1.9 on Fedora 40, but also tried rev 10e50e6 from master and got the same results.
If you have the following layout (I'm just using Alacritty for testing, but giving them letters below so it's easy to tell which window I'm talking about):
H[S[A C] S[B]]
And you issue a move right
on C
, you wind up with:
H[S[A] S[C B]]
Rather than:
H[S[A] S[B C]]
Which is inconsistent with i3.
It's also inconsistent with doing the same thing, but going from right to left. E.g. if you start with:
H[S[A] S[B C]]
And you issue a move left
on C
, you wind up with:
H[S[A C] S[B]]
Which is what I would expect.
I am not at all familiar with sway's code, but went looking for places where moving left is treated differently than moving right and came across container_move_to_container_from_direction
in sway/sway/commands/move.c
. Making the following change fixed the issue for me, but I'm not confident enough to just make a pull request with this change as I'm really not familiar with the code:
diff --git a/sway/commands/move.c b/sway/commands/move.c
index 8891514c..4a0975ce 100644
--- a/sway/commands/move.c
+++ b/sway/commands/move.c
@@ -124,7 +124,7 @@ static void container_move_to_container_from_direction(
} else {
sway_log(SWAY_DEBUG, "Promoting to sibling of cousin");
int offset =
- move_dir == WLR_DIRECTION_LEFT || move_dir == WLR_DIRECTION_UP;
+ move_dir == WLR_DIRECTION_LEFT || move_dir == WLR_DIRECTION_RIGHT;
int index = container_sibling_index(destination) + offset;
if (destination->pending.parent) {
container_insert_child(destination->pending.parent, container, index);
Activity