Improve baseline support across all widgets.#1671
Open
xStrom wants to merge 2 commits intolinebender:mainfrom
Open
Improve baseline support across all widgets.#1671xStrom wants to merge 2 commits intolinebender:mainfrom
xStrom wants to merge 2 commits intolinebender:mainfrom
Conversation
This file contains hidden or 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
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.
The existing baseline support was half-baked to say the least. None of the actual text baselines were ever even piped through!
This PR makes baseline alignment an actual thing for the existing widget set.
FlexandGridreceived CSS spec based baseline implementations.Flexgot it both for child baseline alignment and its own baseline deriving, while forGridI currently only implemented its own baseline deriving.Gridchild baseline alignment remains as future work.Labelwidget always paints the text starting from the top of the widget. So the baseline it reported (from the top) will match what it paints. This would not be true with a bottom-relative baseline if theLabelgets assigned a fractional height that later gets pixel snapped. Our current pixel snapping strategy has no effect on distances from the top of the widget, but changes distances from the bottom.LayoutCtx::derive_baselines(child).LayoutCtx::child_originandLayoutCtx::child_aligned_baselinesthat enable deriving the correct pixel-snapped baseline position. These are basically whatderive_baselinesuses under the hood.LayoutCtx::child_layout_baselineswhich returns the non-snapped baselines. This approach is actually flawed as evidenced by the new (currently incorrectly behaving) testflex_row_baseline_pixel_snapping. There are many potential solutions and none of them trivial, so I've decided to postpone solving it. In the meantime the alignment will semi-work, just not pixel perfect. This is also why I removed the old baseline pixel snapping. That was alignment theater because that rounding had zero effect on any actual drawing. Anyway, this is a deep rabbit hole so I'd like to avoid going deep into it in the context of this PR.FlexcolumnsCrossAxisAlignment::Baselinewas previously defined asCenter. Now withFirstBaselineandLastBaselineI changed the fallback toStartandEndwhich matches CSS, at least in most writing modes and certainly inhorizontal-tbwhich is the only one Masonry currently supports.WidgetStateI usef64::NANto meanNonei.e. no explicit baseline. That's because we have an ever growing size issue with that struct and using actualOption<f64>twice would mean an extra 16 bytes per widget which we can easily avoid withNAN. There are accessor methods for doing proper reading. I could also add setter methods and make the fields private if need be.