-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
feat(dwindle): Rework split logic to be fully gap-aware #12047
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, needs tests :)
Also rebase on main for ci fix
Done, I've added a test handling window spawning position and had to update the split ratio test to expect new numbers based on the changed calculations. Are there any other tests that I should add? PS: sorry for the mess in pr labels, I F'd up the rebase... |
Pretty sure kitty does it by default. I did not set anything. |
vaxerski
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
very nice
|
thank you! |
|
reverting due to #12380 The specified usecase is flawed to begin with. I'll write a better one (using reserved area instead of cursed gaps instead) |
|
or we could just rewrite how gaps out work tbh that'd work too. |

Description:
Related discussion topic
Forum post
This PR enhances the Dwindle layout to correctly handle highly asymmetrical window gaps, fixing the issues demonstrated in the attached videos.
The previous, purely geometric approach to splitting windows didn't account for gaps. This led to incorrect split directions and invalid window sizes in certain edge cases.
The core layout logic in
onWindowCreatedTilingandrecalcSizePosRecursivehas now been reworked to be fully "gap-aware." Splits are calculated based on the true available tiling area, resulting in consistent and intuitive behavior as shown in the "after" video.Workspace rules in the video example
workspace = r[1-1]w[t1-8], gapsout:4 1500 4 4Before
before.mp4
After
after.mp4
Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)
I have tested this on both asymmetrical and standard configurations without issue. As this is a core logic change, wider community testing is needed to ensure full stability.
Is it ready for merging, or does it need work?
That is probably up to discussion.