Renames the top/bottom directions of `goto_split` to up/down. I have
tested this on linux (nixos) but given that `goto_split` is broken on
linux anyway (#2866) there's not a whole lot to test.
I have no way to build on macOS so I can't verify that I've changed
everything correctly for that.
Closes#3237
Fixes#2092
This isn't perfect because it only prevents _new_ splits from being
too small. You can still resize the window to make them smaller. This
just helps prevent the very-easy-to-trigger crash of #2092.
We don't need to do this to macOS because it doesn't crash in the same
way with zero-sized splits.
Long term we should really chase down what breaks in GTK at a root level
when we have zero-sized splits. But this is a quick fix for now to
prevent the easy crash I feel like people might stress test and run into
with the 1.0 release.
When a split is created from a menu action, the focus is lost before the
split is made which prevents the surface from having the
unfocused_widget. Move the logic to add the unfocused_widget to the
overlay to an exported function which is called when the split is
created.
This adds support for the equalize_splits feature that's already
implemented for macOS.
It's essentially a port of the Swift implementation, using the same
weights-mechanism to equalize split sizes.
This adds support for resizing splits via keybinds to the GTK runtime.
Code is straightforward. I couldn't see a way to do it without keeping
track of the orientation of the splits, but I think that's fine.
Before this change, it would crash when you had the following surfaces
split1
/ \
/ \
surf1 \
split2
/ \
surf2 surf3
and you'd want to split `surf1` again. Splitting `surf2` or `surf3`
would be fine, but surf1 would break things.
