layout editor: column drag follows the pointer through the cell floor
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
1 parent
2183317953
commit
4fab14949c
5 files changed
+127
-52
No files matched your search
@@ -138,9 +138,17 @@ Part of [CLAUDE.md](../../CLAUDE.md). These are rules that cost a defect to lear
|
||||
- **Widths are weights with a floor.** The plotter keeps 64 px logical per cell and a column gap
|
||||
(`kColGap`, 6 px); the editor's drag is stricter (below). A weight is a share of what is
|
||||
left *after* the floors, so cells of `{3, 1}` read 533:220 in a 756 px figure, not 3:1, and the
|
||||
editor's 96 px drag floor is a floor on the *share it asks for*: a cell dragged to the limit realises
|
||||
`64 + share * remainder` and reads wider (144 px in the split probe's `pre-insert0` line), so the
|
||||
boundary does not follow the pointer one for one near either extreme.
|
||||
editor's 96 px drag floor is a floor on the *width*, not on the share. Because a cell's width is
|
||||
`64 + extra * weight / total` and not proportional to its weight, `layout_col_apply()` does not scale
|
||||
the pair's weights by the width ratio: it keeps the pair's weight sum `S` from the drag's *start*
|
||||
(`layout_col_drag_start`) and gives the left cell `S * (want_left - 64) / (pair - 128)`, clamped to
|
||||
`[0.001, 0.999]` (the plotter refuses non-positive weights; `0.5` if the pair is not wider than 128).
|
||||
`want_left` is the pointer's width clamped to `[96, pair - 96]` logical px. The divider therefore
|
||||
follows the pointer, the shrinking cell reads 96 px at the extreme and the pair keeps its total width
|
||||
(the split probe's `col-drag` line asserts all three). `kPlotterMinCellPx` (64) mirrors the plotter's
|
||||
`kMinCellWidthLogical`; both are logical px (the plotter scales it by `ui_scale`, which is
|
||||
`PlotArea::device_scale()`, the divisor used to turn layout rects into logical px), so the two
|
||||
must change together.
|
||||
- **A cell is removed with its traces, and a new cell is empty.** `insert_cell(fr, at)` pushes the
|
||||
cells at and after `at` right *with their contents* (the same rule as `insert_row()`), and
|
||||
`remove_cell(plot)` on a one-cell row removes the row. Both return false at a cap or when they would
|
||||
|
||||
Reference in new issue
Block a user