Commit Graph
4 Commits
Author SHA1 Message Date
Sergey Matyunin 5254fb9ef5 fix: reconcile lightweight interaction frames
Issue: #451
User-Visible: no
2026-09-04 22:04:17 +03:00
Matyshandclaude[bot] fc63f3bf36 test: align device drag regression smokes
Issue: #74
User-Visible: no
2026-08-30 13:16:27 +00:00
Matysh 5ca4c7e5c5 v1.59.0-rc.2: make plan editing predictable 2026-08-06 16:48:45 +03:00
Matysh df233905c5 DEV-B58: one bound, one grid — the canvas border and the snap contract
Validate / backend (push) Failing after 8m25s
Validate / smoke (push) Failing after 12m2s
Validate / hassfest (push) Failing after 7s
Validate / hacs (push) Failing after 7s
Validate / frontend (push) Successful in 2m48s
Two owner reports after v1.57.0, both about coordinates.

=== DEV-B58-01: nothing stops at the old canvas border any more ===

The infinite canvas freed the FRAME and the DRAWING; it did not free the
drag handlers, and both the owner and a user hit that within a day:
"названия комнат и устройства не перетаскиваются дальше старых границ
холста".

Two clamps survived v1.57.0, and the second is the worse one:

  * `_pointerMove` (device marker) clamped into `_baseVb()` — the CONTENT
    FRAME, with a 0.8 % inset. A marker could never be dragged past the
    outline of what was already drawn, so a plan could not be extended by
    putting a device where the next room was going to be.
  * `_labelMove` (room label) clamped into `_spaceModel().vb` — the
    space's STORED `view_box`, which is `[0,0,1,1]` for every plan the
    card has ever written. Literally the old square: a room drawn at 2.5
    had a name that could not reach its own room.

And one asymmetry: `_decorCommitDraft` and the decor text anchor had no
guard at all, while `_decorMoveUpdate` did — a draft could be born
outside the range the mover then refused to leave.

The rule now is one line: an editor gesture has exactly ONE bound,
`+/-CANVAS_LIMIT`, the same number `validation.py` enforces, and it is a
garbage limit rather than a frame. `clampCanvasR` / `clampCanvasN` in
space-geometry.ts are the only two functions allowed to impose it, and
`_snap()` applies it on the way out, so every gesture that goes through
the snap is bounded by construction.

demo/smoke_drag_bounds.mjs starts from an ORDINARY plan (rooms inside
0..1, so the old clamps really were in the way), drags a marker, a room
name, a decor shape and an opening far past the old square, checks each
arrives, is stored, survives a rebuild and takes the frame with it — and
that a wild drag still parks at exactly 5000 rather than 1e12. Seven of
its eleven facts fail by name on 85263d5.

=== DEV-B58-02: everything strictly on the grid ===

The owner's suspicion first, answered honestly in docs/CANVAS.md §9.2:
THE GRID STEP DID NOT CHANGE. `_gridPitch = NORM_W / GRID_N = 1000/240`,
both constants, independent of the frame, the view, the zoom, `view_box`
and `cell_cm`; `git log -S` shows neither touched since v1.4.0. So the
move to the infinite canvas did not put any existing element between the
nodes. `gridLevels()` changes what is DRAWN, never what is SNAPPED TO.

What WAS off the grid, and is now fixed:

  * auto placements. `defaultPositions`, the `spaceCenter` fallback and
    an undragged room label used centroids, which are not nodes for an
    odd-sized or polygonal room. This is the likeliest thing the owner
    was actually looking at.
  * `_decorMoveUpdate` snapped the DELTA, which preserves whatever
    off-grid offset a shape already had for ever, one step at a time. It
    snaps the resulting anchor now, so one drag is enough.
  * `snapToGrid`/`snapR` returned 500.00000000000006 for an exact 500 —
    the round trip through a non-dyadic pitch. They are bit-identical on
    a node now, so "is this on the grid?" stops answering no.

Openings and split points on a wall are deliberately NOT rounded to a
node — a door on a node but off its diagonal wall is broken geometry.
They are WALL-bound: projected onto the wall, then the offset ALONG it
quantised to the same step (`snapToWall({step,length})`,
`snapPointAlongPoly`). On the axis-aligned, grid-drawn walls the editor
itself makes, the two rules give the same point. The centre magnet is
consulted FIRST, so a wall whose middle is not a node can still hold a
centred window (this is what smoke_opening_measure caught).

Shift now means one thing everywhere: suspend the snap for this gesture.
It keeps its two older meanings (no centre magnet, coarse 15° compass).

=== And why an ACTION rather than a silent migration ===

Old plans may hold coordinates between the nodes. The card does not
round them on update. General settings grow a Grid group with
«Выровнять всё по сетке», which first states how many elements will
move and by how much at most, warns that there is no undo, and only then
writes — one config/set plus the layout updates, in one go.

  1. A migration moves the user's data without asking. A house plan is a
     drawing; the card has no mandate to redraw it on a version bump.
  2. Some elements are off-grid ON PURPOSE — a small decor label nudged
     next to an icon, a window on a diagonal wall, a plan traced over a
     photo whose scale was never a whole number of cells.
  3. A silent migration is unattributable: when a room looks 3 cm wrong
     the owner cannot tell whether the card did it or they did.
  4. An update that rewrites stored geometry cannot be undone by
     downgrading the card. A button can simply not be pressed.

`alignAllToGrid()` (src/align-grid.ts) is pure — it copies its input and
returns the new spaces, the new layout and the report — so the dialog
measures and commits the SAME object and cannot promise one thing and do
another. test/align-grid.test.mjs pins what moves, what does not (a
stray opening with no wall in reach stays put), that a rect's FAR corner
lands on a node too, and idempotency: a second run reports moved 0,
changed false, and deep-equals the first. demo/smoke_grid_snap.mjs does
the same through the DOM plus every by-hand placement.

docs/CANVAS.md §9 carries the whole contract; docs/TESTING.md gains
three manual items. i18n en/ru. The backend is untouched — same
coordinates, same schema.
2026-08-04 12:42:16 +03:00