Rework split, layout, workspace_layout, and move commands to work like i3 #5756

rpigott · 2020-10-23T19:05:06Z

EDIT: Hijacking top comment b/c this PR is barely related to what it started as anyway

Hey you. Lurker. Please test.

This is intended to match i3's behavior here:

https://github.com/i3/i3/blob/3cd1c45eba6de073bc4300eebb4e1cc1a0c4479a/src/tree.c#L354

Xyene · 2020-10-23T20:00:49Z

Wow, you beat me to the punch here -- I was going to make the same change tonight. The existing container_flatten call is definitely not correct as-is.

However, this isn't quite right (I know you haven't marked it as ready for review yet etc., but anyway). The check for the parent layout to be a [vh]split is actually necessary, because if you have a T[app1] and vsplit, this should result in T[V[app1]], not V[app1].

Probably a good idea to leave a comment linking to the i3 source here, because this is pretty non-obvious.

rpigott · 2020-10-23T20:31:32Z

Fixes #5755, #5754, Re-fixes #5157, #4038.

I ended up going through a bunch of i3-compat issues but I think this matches i3 in the above cases. I don't think 5755 is related to 5754 just my fixes ended up on the same branch.

Yeah thanks @Xyene I forgot to copy that part. I added a comment as suggested.

EDIT: This will probably need some testing

rpigott · 2020-10-23T20:40:56Z

For #4038 OP seems to describe i3 behavior as T[1 2 3] -> H[T[1 2] T[3]] but I can't reproduce this. In i3 I get T[1 2 3] -> T[T[1 2] T[3]].

Xyene · 2020-10-23T22:40:45Z

In i3 I get T[1 2 3] -> T[T[1 2] T[3]].

I'm not entirely sure how... workspace_layout normal, open two windows:

layout tabbed:

move right:

This state is not correct. Subsequent move rights from here toggle between T[app1 T[app2]] and T[app1 app2]. Instead, the transition should be T[app1 app2] → H[T[app1] app2]. This only differs in i3 in that i3 always has the wrapping H for the workspace, whereas Sway often changes the workspace layout itself.

rpigott · 2020-10-24T00:00:15Z

Yeah this is wrong in that case.

This only differs in i3 in that i3 always has the wrapping H for the workspace, whereas Sway often changes the workspace layout itself.

i3 doesn't always wrap workspaces, just when changinging the layout on a single container. Otherwise they change the workspace layout. The difference here is in the behavior of the layout command, which I guess I should also update to match:

https://github.com/i3/i3/blob/3cd1c45eba6de073bc4300eebb4e1cc1a0c4479a/src/con.c#L1817

The case I was trying to get at (and how I interpreted #4038) is

Begin: empty workspace

layout tabbed, open apps, move right. Then the workspace layout changes and I get the T[1 2 3] -> T[T[1 2] T[3]] behavior.

Xyene · 2020-10-24T02:00:02Z

Getting better 👍

The case I described still happens with workspace_layout tabbed, though it has been fixed for workspace_layout normal. (i3 workspace_layout doesn't change the layout of the root workspace container; it changes that of its first-level children.)

rpigott · 2020-10-24T02:25:58Z

i3 workspace_layout doesn't change the layout of the root workspace container; it changes that of its first-level children.

Wow no kidding. In i3 workspace_layout tabbed doesn't make tabbed workspaces but layout tabbed on the workspace does.

The sway(5) man page will probably need to be updated with a proper description of workspace_layout too.

Xyene · 2020-10-24T05:12:54Z

Yeah, it's tricky. Bit of a meta-comment, and you may already have a testing setup that works for you, but I've found the following to be very helpful in comparing i3 with Sway:

script to dump layout, works on both i3 and Sway

$ cat ~/gettree.sh                                                                                                                                    
swaymsg -t get_tree|jq "def f: {name, type, layout, nodes: [.nodes[]|f]}; recurse(.nodes[])|select(.name == \"$1\")|f"
$ ~/gettree.sh 1   # get tree of workspace 1

start Xephyr

$ Xephyr +iglx -br -ac -resizeable -noreset -keybd ephyr,,xkbmodel=evdev :2 &

start i3 within Xephyr

$ unset XDG_RUNTIME_DIR && unset WAYLAND_DISPLAY && DISPLAY=:2 i3

passthrough mode in Sway config so you can use conflicting keybinds within Xephyr i3

mode "passthrough" {
	bindsym $mod+p mode default
}

bindsym $mod+p mode passthrough

rpigott · 2020-10-26T02:52:06Z

So far I've been running i3 in a separate session and sway embedded in gdb. It's a workable setup but could be improved. The i3 layout dump will certainly be handy, I had a basic one but it was still bit of a hassle to interpret. I need to test more i3 layouts

Quick take at matching i3 workspace_layout behavior like https://github.com/i3/i3/blob/e54e88b9e58579b406c5de94b68cb9ad3211eb4e/src/workspace.c#L899, but I'm guessing code will need to be moved somewhere more appropriate than view_map to match all the cases.

Xyene · 2020-10-26T03:44:51Z

The latest commit certainly improves things. I'm generally a fan of keeping the workspace node layout intact (i3-style) over what Sway currently does; it makes debugging i3-compat issues easier.

With workspace_layout tabbed, starting with this layout and move right:

Start state

{
  "name": "1",
  "type": "workspace",
  "layout": "splith",
  "nodes": [
    {
      "name": null,
      "type": "con",
      "layout": "tabbed",
      "nodes": [
        {
          "name": "xyene@lynwood: /code/sway-src/sway",
          "type": "con",
          "layout": "none",
          "nodes": []
        },
        {
          "name": "xyene@lynwood: /code/sway-src/sway",
          "type": "con",
          "layout": "none",
          "nodes": []
        }
      ]
    }
  ]
}

Sway result

{
  "name": "1",
  "type": "workspace",
  "layout": "splith",
  "nodes": [
    {
      "name": null,
      "type": "con",
      "layout": "tabbed",
      "nodes": [
        {
          "name": "xyene@lynwood: /code/sway-src/sway",
          "type": "con",
          "layout": "none",
          "nodes": []
        }
      ]
    },
    {
      "name": "xyene@lynwood: /code/sway-src/sway",
      "type": "con",
      "layout": "none",
      "nodes": []
    }
  ]
}

i3 result

{
  "name": "1",
  "type": "workspace",
  "layout": "splith",
  "nodes": [
    {
      "name": null,
      "type": "con",
      "layout": "tabbed",
      "nodes": [
        {
          "name": "xyene@lynwood: /code/i3",
          "type": "con",
          "layout": "splith",
          "nodes": []
        }
      ]
    },
    {
      "name": null,
      "type": "con",
      "layout": "tabbed",
      "nodes": [
        {
          "name": "xyene@lynwood: /code/i3",
          "type": "con",
          "layout": "splith",
          "nodes": []
        }
      ]
    }
  ]
}

The extracted container should "inherit" the layout of the workspace. (This is effectively what #5157 was about.)

rpigott · 2020-10-30T01:30:18Z

Hopefully improved. I Only tested it in a few cases and had #5761 applied on top.

I moved the change into workspace_add_tiling where it obviously belongs, but lots of places aren't happy to have workspace_add_tiling put their con as a child of a new container instead of the workspace they requested. So, most calls of workspace_add_tiling are changed to something like con = workspace_add_tiling(ws, con) and some of the following references are changed to modify the new con, if there is one.

Xyene · 2020-10-30T01:41:47Z

That case works much better now. Quick testing: starting with a T[app] and doing repeated splitv, you end up with V[V[V[...[V[app]]]]]. The layout didn't change, so only V[app] should have been created.

Xyene · 2020-10-30T01:51:20Z

One more weird case with workspace_layout tabbed where a blank container was created:

Log

(RPigott-consplit) xyene@lynwood:/code/sway-src/sway$ ~/gettree.sh 1                                                                                                                                                                                                                                                        
{
  "name": "1",
  "type": "workspace",
  "layout": "splith",
  "nodes": [
    {
      "name": null,
      "type": "con",
      "layout": "tabbed",
      "nodes": [
        {
          "name": "xyene@lynwood: /code/sway-src/sway",
          "type": "con",
          "layout": "none",
          "nodes": []
        }
      ]
    }
  ]
}
(RPigott-consplit) xyene@lynwood:/code/sway-src/sway$ swaymsg move up
(RPigott-consplit) xyene@lynwood:/code/sway-src/sway$ ~/gettree.sh 1                                                                                                                                                                                                                                                        
{
  "name": "1",
  "type": "workspace",
  "layout": "splith",
  "nodes": [
    {
      "name": "xyene@lynwood: /code/sway-src/sway",
      "type": "con",
      "layout": "none",
      "nodes": []
    }
  ]
}
(RPigott-consplit) xyene@lynwood:/code/sway-src/sway$ swaymsg move up
(RPigott-consplit) xyene@lynwood:/code/sway-src/sway$ ~/gettree.sh 1
{                                                                                                                                                          
   "name": "1",
  "type": "workspace",
  "layout": "splith",
  "nodes": [
    {
      "name": null,
      "type": "con",
      "layout": "tabbed",
      "nodes": [
        {
          "name": "xyene@lynwood: /code/sway-src/sway",
          "type": "con",
          "layout": "none",
          "nodes": []
        }
      ]
    },
    {
      "name": null,
      "type": "con",
      "layout": "tabbed",
      "nodes": [
        {
          "name": null, <--------------------------------- this container is blank
          "type": "con",
          "layout": "splith",
          "nodes": []
        }
      ]
    }
  ]
}
(RPigott-consplit) xyene@lynwood:/code/sway-src/sway$ swaymsg move up                                                                                    
(RPigott-consplit) xyene@lynwood:/code/sway-src/sway$ ~/gettree.sh 1
{
  "name": "1",
  "type": "workspace",
  "layout": "splith",
  "nodes": [
    {
      "name": "xyene@lynwood: /code/sway-src/sway",
      "type": "con",
      "layout": "none",
      "nodes": []
    },
    {
      "name": null,
      "type": "con",
      "layout": "tabbed",
      "nodes": [
        {
          "name": null,
          "type": "con",
          "layout": "splith",
          "nodes": []
        }
      ]
    }
  ]
}
(RPigott-consplit) xyene@lynwood:/code/sway-src/sway$ swaymsg move up                                                                                    
(RPigott-consplit) xyene@lynwood:/code/sway-src/sway$ ~/gettree.sh 1
{
  "name": "1",
  "type": "workspace",
  "layout": "splith",
  "nodes": [
    {
      "name": null,
      "type": "con",
      "layout": "tabbed",
      "nodes": [
        {
          "name": "xyene@lynwood: /code/sway-src/sway",
          "type": "con",
          "layout": "none",
          "nodes": []
        }
      ]
    },
    {
      "name": null,
      "type": "con",
      "layout": "tabbed",
      "nodes": [
        {
          "name": null,
          "type": "con",
          "layout": "splith",
          "nodes": []
        }
      ]
    }
  ]
}

rpigott · 2020-10-31T20:00:55Z

Quick testing: starting with a T[app] and doing repeated splitv, you end up with V[V[V[...

Oops, pushed the corrected version of that commit.

One more weird case with workspace_layout tabbed where a blank container was created

I don't observe that with your #5761 applied. I guess it gets reaped.

Xyene · 2020-10-31T20:34:52Z

Exciting, it's getting there :)

I don't observe that with your #5761 applied. I guess it gets reaped.

You're right, oops.

It does seem that some extraneous containers are still being created with workspace_layout tabbed:

Log

(RPigott-consplit) xyene@lynwood:/code/sway-src/sway$ ~/gettree.sh 1                                                                                        
{
  "name": "1",
  "type": "workspace",
  "layout": "splith",
  "nodes": [
    {
      "name": null,
      "type": "con",
      "layout": "tabbed",
      "nodes": [
        {
          "name": "xyene@lynwood: /code/sway-src/sway",
          "type": "con",
          "layout": "none",
          "nodes": []
        },
        {
          "name": "xyene@lynwood: /code/sway-src/sway",
          "type": "con",
          "layout": "none",
          "nodes": []
        }
      ]
    }
  ]
}
(RPigott-consplit) xyene@lynwood:/code/sway-src/sway$ swaymsg move right
(RPigott-consplit) xyene@lynwood:/code/sway-src/sway$ ~/gettree.sh 1
{                                                                          
  "name": "1",
  "type": "workspace",
  "layout": "splith",
  "nodes": [
    {
      "name": null,
      "type": "con",
      "layout": "tabbed",
      "nodes": [
        {
          "name": "xyene@lynwood: /code/sway-src/sway",
          "type": "con",
          "layout": "none",
          "nodes": []
        }
      ]
    },
    {
      "name": null,
      "type": "con",
      "layout": "tabbed",
      "nodes": [
        {
          "name": "xyene@lynwood: /code/sway-src/sway",
          "type": "con",
          "layout": "none",
          "nodes": []
        }
      ]
    }
  ]
}
(RPigott-consplit) xyene@lynwood:/code/sway-src/sway$ swaymsg move up
(RPigott-consplit) xyene@lynwood:/code/sway-src/sway$ ~/gettree.sh 1   
{
  "name": "1",
  "type": "workspace",
  "layout": "splith",
  "nodes": [
    {
      "name": null,
      "type": "con",
      "layout": "tabbed",
      "nodes": [
        {
          "name": "xyene@lynwood: /code/sway-src/sway",
          "type": "con",
          "layout": "none",
          "nodes": []
        }
      ]
    },
    {
      "name": null,
      "type": "con",
      "layout": "tabbed",
      "nodes": [
        {
          "name": null,
          "type": "con",
          "layout": "splith",
          "nodes": [
            {
              "name": null,
              "type": "con",
              "layout": "tabbed",
              "nodes": [
                {
                  "name": "xyene@lynwood: /code/sway-src/sway",
                  "type": "con",
                  "layout": "none",
                  "nodes": []
                }
              ]
            }
          ]
        }
      ]
    }
  ]
}
(RPigott-consplit) xyene@lynwood:/code/sway-src/sway$ swaymsg move up    
(RPigott-consplit) xyene@lynwood:/code/sway-src/sway$ ~/gettree.sh 1    
{
  "name": "1",
  "type": "workspace",
  "layout": "splith",
  "nodes": [
    {
      "name": null,
      "type": "con",
      "layout": "tabbed",
      "nodes": [
        {
          "name": "xyene@lynwood: /code/sway-src/sway",
          "type": "con",
          "layout": "none",
          "nodes": []
        }
      ]
    },
    {
      "name": null,
      "type": "con",
      "layout": "tabbed",
      "nodes": [
        {
          "name": null,
          "type": "con",
          "layout": "splith",
          "nodes": [
            {
              "name": null,
              "type": "con",
              "layout": "tabbed",
              "nodes": [
                {
                  "name": null,
                  "type": "con",
                  "layout": "splith",
                  "nodes": [
                    {
                      "name": null,
                      "type": "con",
                      "layout": "tabbed",
                      "nodes": [
                        {
                          "name": "xyene@lynwood: /code/sway-src/sway",
                          "type": "con",
                          "layout": "none",
                          "nodes": []
                        }
                      ]
                    }
                  ]
                }
              ]
            }
          ]
        }
      ]
    }
  ]
}
(RPigott-consplit) xyene@lynwood:/code/sway-src/sway$ swaymsg move up    
(RPigott-consplit) xyene@lynwood:/code/sway-src/sway$ ~/gettree.sh 1    
{
  "name": "1",
  "type": "workspace",
  "layout": "splith",
  "nodes": [
    {
      "name": null,
      "type": "con",
      "layout": "tabbed",
      "nodes": [
        {
          "name": "xyene@lynwood: /code/sway-src/sway",
          "type": "con",
          "layout": "none",
          "nodes": []
        }
      ]
    },
    {
      "name": null,
      "type": "con",
      "layout": "tabbed",
      "nodes": [
        {
          "name": null,
          "type": "con",
          "layout": "splith",
          "nodes": [
            {
              "name": null,
              "type": "con",
              "layout": "tabbed",
              "nodes": [
                {
                  "name": null,
                  "type": "con",
                  "layout": "splith",
                  "nodes": [
                    {
                      "name": null,
                      "type": "con",
                      "layout": "tabbed",
                      "nodes": [
                        {
                          "name": null,
                          "type": "con",
                          "layout": "splith",
                          "nodes": [
                            {
                              "name": null,
                              "type": "con",
                              "layout": "tabbed",
                              "nodes": [
                                {
                                  "name": "xyene@lynwood: /code/sway-src/sway",
                                  "type": "con",
                                  "layout": "none",
                                  "nodes": []
                                }
                              ]
                            }
                          ]
                        }
                      ]
                    }
                  ]
                }
              ]
            }
          ]
        }
      ]
    }
  ]
}

rpigott · 2020-11-01T23:44:51Z

The commit I removed was just one that had commented out some code. Now workspace_wrap_children now doesn't double wrap, that was creating some extra containers.

So here's an interesting layout with workspace_layout tabbed:

begin -> H[T[app app*]]
move right -> H[T[app] T[app*]] (matches i3)
move up -> V[T[app*] H[T[app]]] (matches i3, your scenario above)
move right -> H[V[H[T[app]]] T[app*]] (sway), H[T[app] T[app*]] (i3)

In the last move, though it's pretty unwieldy, the sway layout is the one that matches my mental model of the i3 tree. I'd guess it's special cased somewhere, but atm I'm not sure what i3 is doing here to get the simpler layout.

Xyene · 2020-11-02T00:38:57Z

I'd guess it's this:

https://github.com/i3/i3/blob/1f0c628cde40cf87371481041b7197344e0417c6/src/tree.c#L638-L651

/*
 * tree_flatten() removes pairs of redundant split containers, e.g.:
 *       [workspace, horizontal]
 *   [v-split]           [child3]
 *   [h-split]
 * [child1] [child2]
 * In this example, the v-split and h-split container are redundant.
 * Such a situation can be created by moving containers in a direction which is
 * not the orientation of their parent container. i3 needs to create a new
 * split container then and if you move containers this way multiple times,
 * redundant chains of split-containers can be the result.
 *
 */
void tree_flatten(Con *con) {

Called right at the end of tree_move on croot, which looks like, well, the root of the workspace: https://github.com/i3/i3/blob/1f0c628cde40cf87371481041b7197344e0417c6/src/move.c#L388

We don't have a version of this in Sway AFAICT; container_flatten moves up the tree rather than down it.

rpigott · 2020-11-11T19:46:38Z

Rebased on master again so the CI can build.

Xyene · 2020-11-13T04:18:16Z

So far, so good. I haven't encountered any major issues in the last 2 days, so that's encouraging.

Here's a small one, though:

start with T[H[app* app]]
focus parent
splith (multiple times)

The resulting layout is something like T[H[H[H[H[...H[app app]]]]]. In i3, the spliths remain a no-op.

@RedSoxFan, do you have any thoughts on this PR? I think it's roughly in a state where it could be merged: I think that some corner cases might still be wrong, but by and large it's less finicky than current master.

ChrisLane · 2020-11-13T08:56:56Z

Briefly tested this branch, it seems to fix nwg-piotr/autotiling#19

rpigott · 2020-11-13T09:02:07Z

The resulting layout is something like T[H[H[H[H[...H[app app]]]]]. In i3, the spliths remain a no-op.

Hmm I'm not able to reproduce. After the focus parent the H split is focused, right? In this branch and in i3 I get T[H[H[app app]*]] after the split and then all further splith's are no-ops. Actually it seems if you focus parent again in both this branch and i3 you can get more H[ by splith'ing the topmost H.

Something is fishy with workspace layouts still. Without setting workspace_layout in my config if I layout tabbed an empty workspace in i3 and open a new window I actually get T[T[app]] as if workspace_layout tabbed was set. I made several mistakes trying to create T[H[app app]] in i3 because of that.

Xyene · 2020-11-13T15:08:00Z

Hmm I'm not able to reproduce. After the focus parent the H split is focused, right?

Yes, though oddly I haven't been able to reproduce this since. What I feel (since my memory isn't that good) was happening was the new container was getting focus, as opposed to the old one keeping it. At any rate, without being able to reproduce this, it's not worth worrying about now.

Without setting workspace_layout in my config if I layout tabbed an empty workspace in i3 and open a new window I actually get T[T[app]] as if workspace_layout tabbed was set.

But... not quite? On i3 with workspace_layout tabbed and opening a single application, you get H[T[app]] (the workspace node layout is splith). But if you layout tabbed before opening the application (still workspace_layout tabbed), you get T[T[app]] (workspace node layout is tabbed). This matches the behavior in this PR, AFAICT.

Edit: I just understood what you mean... yeah, that behavior from i3 feels pretty strange to me.

Xyene · 2020-11-21T04:23:55Z

I've been running this for the past week with no deal-breaking issues. In general, I'd be comfortable with merging this before we get an authoritative response regarding layout tabbed on an empty workspace — that's a pretty niche scenario. Probably worth another round of rebasing to get this in a mergeable state.

On the "of some concern" list, I've noticed Firefox (84.0b3) geometries are wrong when floated out of the tiling layer. I'm not sure if this is caused by this patch (the geometry resetting?) or by a regression in Firefox, but at least I wasn't able to (easily) reproduce this issue in Sway master.

Screenshot

In i3 splits are ineffective on singleton H/V containers, and the command is interpreted to affect the parent layout instead.

In i3 the layout command on a workspace affects the workspace layout only on empty workspaces. Otherwise children are placed in a new container with the desired layout to preserve the workspace layout.

Some comparisons of current Sway versus i3 behavior: 1) T[T[T[app]]] + move left * Sway: T[app] * i3: T[T[app]] 2) H[V[H[V[app]]]] + move left * Sway: H[app] * i3: H[V[app]] After this commit, Sway behavior matches i3. The intermediate states are now: T[T[T[app]]] -> T[T[app T[]]] -> T[T[app]] H[V[H[V[app]]]] -> H[V[app H[V[]]]] -> H[V[app]]

This is in preparation for changing the workspace_layout command to work like it does in i3. This reverts commit b4a75a1.

In i3, the workspace_layout command does not affect the workspace layout. Instead, new workspace level containers are wrapped in the desired layout and the workspace layout always defaults to the output orientation.

This changes the move command to better match i3 behavior after the layout changes. workspace_rejigger handled the case where containers would escape their workspace in an orthogonal move by changing the layout to accomodate them, but this case is now handled within the loop.

workspace_squash is container_flatten in the reverse direction. Instead of eliminating redundant splits that are parents of the target container, it eliminates pairs of redundant H/V splits that are children of the workspace. Splits are redundant if a con and its grandchild have the same layout, and the immediate child has the opposite split. For example, layouts are transformed like: H[V[H[app1 app2]] app3] -> H[app1 app2 app3] i3 uses this operation to simplify the tree after moving heavily nested containers to a higher level in the tree via an orthogonal move.

rpigott · 2020-11-21T05:58:09Z

On the "of some concern" list, I've noticed Firefox (84.0b3) geometries are wrong when floated out of the tiling layer.

I tried FF83 and 84 but it doesn't seem to happen for me. Is it reproducible everytime for you? Is there a chance it's fixed by #5812? I think I'm running that one too.

Probably worth another round of rebasing to get this in a mergeable state.

Done.

Xyene · 2020-11-30T01:57:45Z

Is it reproducible everytime for you? Is there a chance it's fixed by #5812? I think I'm running that one too.

Unfortunately yes, and partially.

#5812 does seem to prevent the issue from being permanent (once Firefox is in a bad state, it sends another configure a bit later, which after #5812 fixes the borders). Here's a video.

There are at least two issues:

When the window is floated, the border is drawn at the wrong position for 200ms (presumably it's waiting for Firefox to ack a configure?), and Firefox never does(?) so the transaction times out.

00:06:55.442 [sway/desktop/transaction.c:505] Transaction 0x5603c03bbae0 is ready
00:06:55.442 [sway/desktop/transaction.c:281] Applying transaction 0x5603c03bbae0
00:06:55.443 [sway/desktop/transaction.c:428] Transaction 0x5603c03d72b0 committing with 1 instructions
00:06:55.443 [sway/input/cursor.c:901] denying request to set cursor from unfocused client
00:06:55.443 [sway/input/cursor.c:901] denying request to set cursor from unfocused client
00:06:55.643 [sway/desktop/transaction.c:389] Transaction 0x5603c03d72b0 timed out (1 waiting)
00:06:55.643 [sway/desktop/transaction.c:281] Applying transaction 0x5603c03d72b0

I don't think this is blocking for merging this PR, since it might just be a Firefox-side issue.

When the window is un-floated, there is a frame where the split indicator border is drawn incorrectly (my indicator color is red)

This is frame 118/550 of the video. I suspect this is happening as the floated container is being split on being added back into the tiling layer, prior to being squashed again.

Changes workspace prev|next commands to visit each numbered or named workspace first before considering workspace from the other category

rpigott · 2020-12-05T03:36:38Z

Latest commit fixes #5783 but workspace {prev,next}_on_output will need the same treatment. Normally I'd make a different PR but it's just easier to have one big i3 compat branch for testing, especially when they might conflict. It should be easy enough to split later if we want.

As for firefox, it turns out #5812 was pretty buggy and I think it's related. I'm not sure yet how #5848 and #5857 will be resolved but I have a hunch their closure might address the firefox issue as well, or at least make it easier to debug.

Xyene

In the interest of getting more eyes on this and preventing this branch getting stale, I'll go ahead and merge this now. Irrespective of any outstanding bugs this is already a great improvement over the status quo. Thanks for working on this!

rpigott marked this pull request as draft October 23, 2020 19:09

rpigott force-pushed the consplit branch 2 times, most recently from 6f541c4 to 7ee8a53 Compare October 23, 2020 20:21

rpigott marked this pull request as ready for review October 23, 2020 20:31

emersion requested a review from Xyene October 23, 2020 20:58

rpigott force-pushed the consplit branch from f3be3bb to cad6df6 Compare October 24, 2020 01:30

Xyene added the i3-compat Sway doesn't match i3's behavior label Oct 25, 2020

Xyene mentioned this pull request Oct 25, 2020

commands/move: don't flatten on move; reap empty former parent instead #5761

Closed

rpigott force-pushed the consplit branch from 08ff5a9 to e06673f Compare October 30, 2020 01:20

rpigott force-pushed the consplit branch from e06673f to 7bb6499 Compare October 31, 2020 19:49

rpigott changed the title ~~container: don't split single children~~ Rework split, layout, and workspace_layout to work like i3 Oct 31, 2020

rpigott force-pushed the consplit branch from 7bb6499 to 9a59391 Compare November 1, 2020 23:26

rpigott force-pushed the consplit branch from 9a59391 to 4e1513b Compare November 2, 2020 07:20

rpigott force-pushed the consplit branch from 49e4b3d to b3ed645 Compare November 11, 2020 19:42

Xyene mentioned this pull request Nov 13, 2020

Strange interaction of layout tabbed with workspace_layout i3/i3#4255

Closed

Ronan Pigott and others added 9 commits November 20, 2020 22:27

container: don't split single children

20705c3

In i3 splits are ineffective on singleton H/V containers, and the command is interpreted to affect the parent layout instead.

commands/layout: don't change the layout of workspaces with children

7149ba7

In i3 the layout command on a workspace affects the workspace layout only on empty workspaces. Otherwise children are placed in a new container with the desired layout to preserve the workspace layout.

Revert "commands/move: maintain workspace_layout when moving"

77b2bb5

This is in preparation for changing the workspace_layout command to work like it does in i3. This reverts commit b4a75a1.

Change workspace_layout to match i3 behavior

99cf898

In i3, the workspace_layout command does not affect the workspace layout. Instead, new workspace level containers are wrapped in the desired layout and the workspace layout always defaults to the output orientation.

commands/move: squash workspace after directional con move

2a7527e

commands/move: reset geometry of promoted containers

cbf727b

rpigott force-pushed the consplit branch from b3ed645 to cbf727b Compare November 21, 2020 05:59

workspace: rework workspace prev|next like i3

6576ac0

Changes workspace prev|next commands to visit each numbered or named workspace first before considering workspace from the other category

Xyene approved these changes Dec 20, 2020

View reviewed changes

Xyene linked an issue Dec 20, 2020 that may be closed by this pull request

Workspace switching order is different from i3's when using multiple outputs #5783

Closed

Xyene merged commit 5f1fe33 into swaywm:master Dec 20, 2020

rpigott mentioned this pull request Dec 21, 2020

Change workspace ordering in workspace {prev,next}_on_output #5900

Closed

rpigott deleted the consplit branch December 21, 2020 03:04

Xyene mentioned this pull request Jan 1, 2021

Representation does not update on window moves #5925

Closed

rpigott mentioned this pull request Jan 6, 2021

Unnecessarily nesting tabs when opening programs #5930

Open

Xyene mentioned this pull request Feb 17, 2021

Extra split when escaping container #5754

Closed

Rework split, layout, workspace_layout, and move commands to work like i3 #5756

Rework split, layout, workspace_layout, and move commands to work like i3 #5756

Uh oh!

Conversation

rpigott commented Oct 23, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Xyene commented Oct 23, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rpigott commented Oct 23, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rpigott commented Oct 23, 2020

Uh oh!

Xyene commented Oct 23, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rpigott commented Oct 24, 2020

Uh oh!

Xyene commented Oct 24, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rpigott commented Oct 24, 2020

Uh oh!

Xyene commented Oct 24, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rpigott commented Oct 26, 2020

Uh oh!

Xyene commented Oct 26, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rpigott commented Oct 30, 2020

Uh oh!

Xyene commented Oct 30, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Xyene commented Oct 30, 2020

Uh oh!

rpigott commented Oct 31, 2020

Uh oh!

Xyene commented Oct 31, 2020

Uh oh!

rpigott commented Nov 1, 2020

Uh oh!

Xyene commented Nov 2, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rpigott commented Nov 11, 2020

Uh oh!

Xyene commented Nov 13, 2020

Uh oh!

ChrisLane commented Nov 13, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rpigott commented Nov 13, 2020

Uh oh!

Xyene commented Nov 13, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Xyene commented Nov 21, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rpigott commented Nov 21, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Xyene commented Nov 30, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rpigott commented Dec 5, 2020

Uh oh!

Xyene left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

rpigott commented Oct 23, 2020 •

edited

Loading

Xyene commented Oct 23, 2020 •

edited

Loading

rpigott commented Oct 23, 2020 •

edited

Loading

Xyene commented Oct 23, 2020 •

edited

Loading

Xyene commented Oct 24, 2020 •

edited

Loading

Xyene commented Oct 24, 2020 •

edited

Loading

Xyene commented Oct 26, 2020 •

edited

Loading

Xyene commented Oct 30, 2020 •

edited

Loading

Xyene commented Nov 2, 2020 •

edited

Loading

ChrisLane commented Nov 13, 2020 •

edited

Loading

Xyene commented Nov 13, 2020 •

edited

Loading

Xyene commented Nov 21, 2020 •

edited

Loading

rpigott commented Nov 21, 2020 •

edited

Loading

Xyene commented Nov 30, 2020 •

edited

Loading