Fix layout gap #408
Merged
Fix layout gap #408
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
joshka
requested review from
orhun,
mindoodoo,
sayanarijit,
sophacles and
kdheepak
as code owners
Codecov Report
@@ Coverage Diff @@
## main #408 +/- ##
==========================================
- Coverage 86.14% 86.13% -0.02%
==========================================
Files 40 40
Lines 9256 9240 -16
==========================================
- Hits 7974 7959 -15
+ Misses 1282 1281 -1
|
joshka
force-pushed
the
layout-gap
branch
2 times, most recently
from
58063db to
230e8a5
Compare
kdheepak
reviewed
Aug 17, 2023
a-kenji
reviewed
Aug 17, 2023
Previously the layout used the floor of the calculated start and width as the value to use for the split Rects. This resulted in gaps between the split rects. This change modifies the layout to round to the nearest column instead of taking the floor of the start and width. This results in the start and end of each rect being rounded the same way and being strictly adjacent without gaps. Because there is a required constraint that ensures that the last end is equal to the area end, there is no longer the need to fixup the last item width when the fill (as e.g. width = x.99 now rounds to x+1 not x). The colors example has been updated to use Ratio(1, 8) instead of Percentage(13), as this now renders without gaps for all possible sizes, whereas previously it would have left odd gaps between columns.
|
Rebased on main to pickup the bug fix in #408 Removed the no longer necessary comment in tests. I also removed the code that checked the last element filled the area as the required constraint and corrected rounding take care of that fully now. I can't think of any possible way to trigger this code to mis-allocate the last constraint to less than the full amount that wouldn't also panic earlier due. Prior to this change, this was possible when the code took the floor of the start and floor of the width. E.g.: with area of 10:
|
kdheepak
approved these changes
Aug 18, 2023
orhun
approved these changes
Aug 18, 2023
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #367
Note: this builds on #405, so it has the commits for that here.Look at just the last commit in this PR to understand it. The relevant change is just the addition ofround():https://github.com/ratatui-org/ratatui/blob/2364d9b3098024459c4360900228e2b3e79fb848/src/layout.rs#L453-L454
Note each of the test changes is a subjectively better rendering choice. I'm not 100% sure if there are some tests that would make it easier to see this change's effect rather than those that are already changed.
I updated the colors example to use a ratio instead of a percentage as this now renders correctly without gaps.
Before (using
constraint: vec![Ratio(1,8); 8])After: