Dwindle: Make resize more intuitive

[DanielAdolfsson]

Describe your PR, what does it fix/add?

This improves resizing to make it a little more intuitive. It allows you to to change the size by dragging any corner of the window while anchoring the opposite side.

I think this issue is related:
#2112

Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)

Not currently.

Is it ready for merging, or does it need work?

Couple of questions:

Should this behavior be opt-in?
When using keyboard resizing, should we use the old behavior?

[vaxerski]

with keyboard resizing we should keep how it used to be imo, you can achieve that by adding a CORNER_NONE to the enum and using that as default

[DanielAdolfsson]

Sure! The original code only allows two axis of freedom if the parent's immediate parent has another orientation. My proposal is we keep traversing the tree (as in the new behavior) to find a suitable parent.

Not exactly what you asked for, but maybe good anyway. This way we can use the same code with minor modifications. Up to you!

[vaxerski]

looks alright

[Ashe]

This works really well!! Thank you so much!

I wanted to make a note of some behaviour I found though. Given this layout:

   |   |   |
 1 |   | 3 |
   |   |   |
---| 2 |---|
   |   |   |
 4 |   | 5 |
   |   |   |

Dragging any corners of window 2 works as expected, only the the vertical split between 2 and the side splits (1 and 4, or 3 and 5) moves, leaving the other split and the opposite windows in the exact the same positions and size.

However, dragging on the 'inner' corners of the side windows (1, 4, 3 or 5) can result in the opposite windows being affected. The corner that triggers this is decided by the order you spawn and the way you position windows, but for example right now if I drag window 4, not only do the 1-4 and 1-2/4-2 splits move, but so does the opposite vertical split (2-3/2-5). Subtle but noticeable. Things still works great and this feature makes it easy to rectify things, since only one side of window 2 gets this bug you can easily resize things how they should be on the side that moved without you asking.

Does this help?

[DanielAdolfsson]

Yes, it's a limitation with the implementation now. When you resize the window - in order to guarantee that it doesn't move around, it might need to update the split ratios of a secondary parent. In certain situations that will make the other elements shrink/grow. The behavior is technically correct, but it might look weird.

It's possible to make this update recursively and make stuff move around less, but I think this is good enough for a first version. But you're welcome to open a new issue to improve this. :)

[Ashe]

Yes, agreed, this is more than I could ask for as a first pass, the main things are all there! I just wanted to raise it in case you weren't aware :) Thank you so much for your hard work