-
-
Notifications
You must be signed in to change notification settings - Fork 651
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reimplement resize code #1990
Reimplement resize code #1990
Conversation
For anyone interested in trying this out, here's a binary with the new resize behavior implemented: zellij.zip Add this snippet into your config to replace the current "Resize" keybindings:
|
Hey @har7an - very happy to see this! I haven't looked at the code, but a quick note: not sure if you were planning on doing this, but can we please also add this to the default config? |
Totally, I just wanted to discuss sensible options for the default keybindings before doing so. I like |
How about |
Here's the current state: zellij.zip Best enjoyed with |
c5a9070
to
38b5940
Compare
in floating panes code.
which was previously present in multiple locations. Also start working on a new Resize Method (type `ResizeStrategy`), to remove code duplication in the resize code.
with the `ResizeStrategy` type. Add a new action with the ability to invoke it from the CLI. Take care to maintain backwards-compatibility in terms of configuring the new resize mode.
from `data::Direction`.
but it's currently still broken in a few regards and misses ability to perform "regular" increase/decrease.
to catch if the total area of all panes (in percent) is different from 100.0 at some point.
caused by the fact that neighboring plugin panes previously weren't filtered from resize operations, even though they cannot be resized at all.
that controls whether we invert resize behavior when increasing size towards a bounadry. This maintains current behavior.
in `ResizeStrategy`
without specifying a direction (towards all possible directions). Currently broken in some cases.
to preserve resize debug assertions.
caused by checking for the wrong alignments in some cases. Also refactor the code for looking up aligned panes.
and remove log statements and unused functions.
if the floating pane is hitting a boundary already.
with new functions and result types.
behavior which would previously, upon hitting a boundary, cause the pane to invert the resize operation, which is wrong. Instead, it now does not resize floating panes on an undirected resize "increase" in directions where it hits boundaries.
The values for the resize increments were previously wrong, causing many of the tests to fail.
to correctly consider fixed-size panes.
with new keybindings for resize mode.
type in `change_pane_size` function.
for undirected resizes, to the way it was before this PR.
for undirected resizes
for tests working with the default config
@imsnif I'm going with the following keybindings now:
I found no keybinding to bind decreasing resizes to that includes the arrow keys. Is that ok? |
58f58c3
to
cb08b2c
Compare
@har7an why not use |
Because it conflicts with the Alt+Arrow keybindings for movement. I don't think this is a good idea for a number of reasons:
Regarding point 2: This is the current config:
We'll have to change it to:
and then add the "basic" keybindings back into resize mode manually. Or am I missing something? In this case I'd prefer to announce this new feature in the changelog, maybe add a comment with the |
Well argued @har7an - I'm convinced. :) |
This PR reimplements the code for resizing tiled and floating panes and adds new resizing methods along the way.
Scope of this PR
It started out removing more
unwrap
statements from the code inserver::panes
. I realized that much of the code for resizing panes is duplicated and changes only in minor aspects (using x or y coordinates, etc.). I decided to rewrite/merge the individual functions to reduce duplicate code and get a better grasp on how resizing works. While doing so I introduced a new data type (the newResize
action) to facilitate this work.New features
This PR adds the ability to actively decrease pane sizes. Previously, resizing a pane would always increase that panes area, unless the border in the direction being resized hit the viewport boundary, in which case the opposite border was moved (reducing pane area).
Now, a "reducing" resize can be bound to keys, like so:
and is also accessible from the CLI:
Given the keybinding above and e.g. a floating pane, one can now:
h
to move the left border outwards (increase area)H
to move the left border inwards (decrease area)What has changed
UI changes
From the users perspective almost nothing changed. The hints in the status bar have been renamed to reflect the new behavior, the documentation has been modified where appropriate. Care has been taken to maintain compatibility with existing configs. Hence, a keybinding:
does exactly the same as
because "Increase" is the default which is assumed when nothing else is specified. Previous resize behavior, where an "increasing" resize towards a viewport boundary decreases the panes area from the other side, is maintained, too.
Breaking change: The generic increase/decrease (without a direction specified) will now increase/decrease tiled panes into every direction unlike previously, where a number of preferred directions was tried in order until the first one worked. I'm not sure whether this is a bad thing, personally I prefer the new resize behavior. I'm open to discuss this, however.
From a developers perspective
The
Resize
type has been extended to allow for greater flexibility and extensibility in the future. The resizing code has been streamlined and was compacted into fewer functions.Current quirks
Some resize operations shift neighboring panes positions around slightly. I assume this is a side-effect from the code for "solving" pane layouts but haven't extensively tested this yet. This is likely the reason why some of the server tests fail, too.