Splitpane drag symmetry - #211
Merged
Merged
Conversation
ratioAt biased the pointer->ratio mapping by half a cell (rel = col - at.x + 1, divided by width), so drags reached ratio 1.0 on the right but never near 0.0 on the left. Map the first/last cell to 0.0/1.0 by using rel = col - at.x over a (width-1) denominator, giving a symmetric [0,1] raw range before clampRatio. Same fix for the Vertical branch. Update existing drag tests that encoded the old mapping and add a symmetry regression.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
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
1 participant
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.
DECISIONS — splitpane-drag-symmetry (fixes #208)
Problem
SplitPane.ratioAtmapped pointer→ratio asymmetrically. Withat.x = 1theold code computed
rel = col - at.x + 1(range1..width) and divided bywidth, giving a raw ratio range of[1/width, 1]. The far-right edge reached1.0but the far-left edge bottomed out at1/width, never near0— ahalf-cell bias that broke symmetry about the centre.
Change
modules/termflow-widgets/.../SplitPane.scala,ratioAt:+1:rel = col - at.x.value(range0..width-1).denom = max(1, span - 1)instead ofspan.Result: first/last cells map to exactly
0.0/1.0, so the reachable rawratio is a symmetric
[0, 1]about0.5beforeclampRatio. Applied the samecorrection to the
Verticalbranch (usingrow/height).Why
width - 1, not just dropping+1The issue offered "drop the
+1and/or divide bywidth - 1". Dropping+1alone (still/width) yields[0, (width-1)/width]— reaches0but not1, still asymmetric. Only/(width-1)puts both endpoints symmetric, which isthe stated goal. Guarded
denom/span-1withmax(1, …)sowidth == 1(single-cell region) can't divide by zero.
Tests
/widthmapping (Dragcol=15→14/19, Releasecol=5→4/19, Verticalrow=8→7/15). These had to change — they asserted the buggy mapping byconstruction; no symmetric denominator keeps
col/widthvalues like0.75.dcells from each endproduce ratios summing to
1.0(mirror about0.5); (b) far-left/far-rightdrags hit the exact raw endpoints
0.0/1.0.Risk
Low. Behaviour change is confined to drag-resize ratio;
clampRatio(
MinSizeRatio = 0.05) still bounds the committed ratio, and layout math isunchanged. The only observable difference is that mid-drag ratios shift
slightly (denominator
width-1vswidth) and the divider now reaches bothextremes evenly.