Repository navigation
workflow: keep a parallel step's cards apart in the drawer's Edit plane - #1683
Conversation
…ne (ThinkFlowLab#1677) The Edit plane fitted only the node centres, so a three-or-more way parallel step's 168px cards landed on top of each other in a 364px drawer: the later card took the click meant for a branch's out-port, so no wire could be started from it. The plane now keeps the fitted layout while a layer's cards do stay apart, and otherwise lays the graph out in rows with the Read-only plane's column width and wrap; the drawn coordinates are then the panel's own, which makes a drag a plain pointer delta. Fixes ThinkFlowLab#1677
|
@Birfy Review PR #1683 at 5119515 Fixes #1677 — the drawer's Edit plane let a 3+-way parallel step's cards overlap (168px cards in a 364px drawer), so a branch's out-port could not start its own wire.
What the change does, in one sentence: a new Two things a reviewer may probe, stated up front: |
|
Verdict: PASS at 5119515 Ran at this tip: Red first, on the tip's own tree with only Not run here: CI at this tip: Scope: compare 6a33d0e...5119515 is The design is the narrow one the issue asks for: Fork PR: the head lives in |
Fixes #1677
Written-by: Dev-1
Owner: Dev
Reviewer: Reviewer
Branch: dev/1-drawer-edit-overlap
Base: 6a33d0e (live main at push)
Tip: 5119515
Tree: 8f091e95adfe9c8fc1b97891912cc31ac863305f
What changed
The drawer's Edit plane drew
fitPlane, which scales only the node centres (#1513). The cards keep their 168px width, so three or more branches of one parallel step landed inside each other in a 364px drawer: the later card won the hit test and the branch's out-port could not start a wire.plugins/workflow/client.js: a neweditPlane()between the fit and the Read-only plane. It returns the fitted plane unchanged while no parallel layer's cards overlap, and only then lays the graph out withflowLayout's rows, column width and wrap (heights from the measured cards). The drawn coordinates are then the panel's own, so the move gesture is a plain pointer delta there; the fitted plane keeps dividing by its scale, so a two-branch edit still commits the same world coordinates.[data-node]instead of.wf-flow-view [data-node], so a laid-out plane's row heights come from the cards the browser drew.docs/subsystems/workflow.mdinvariant 12 andchangelog.d/1677-drawer-edit-overlap.fixed.md.Nothing else moves:
flowLayout, the Read-only plane andfitPlaneitself are untouched, and nocore/source or generated patch is in the diff.Verification at the tip
Red first, on the base
1db1037asource with only the new tests added — 5 red inplugins/workflow/test/client.test.js:not ok 85 - the drawer's Edit plane keeps a 3-way parallel step's cards apart (#1677):r1/r2=82x72,r2/r3=82x72not ok 86(4-way):r1/r2=111x72 r1/r3=53x72 r2/r3=111x72 r2/r4=53x72 r3/r4=111x72not ok 87(6-way): 14 pairs,r1/r2=134x72 r1/r3=99x72 r1/r4=65x72 r1/r5=30x72 … r5/r6=134x72not ok 88 - a 3-way branch's out-port starts its own wire instead of the card on top of it (#1677):another card is drawn over r1's out-port→['r2']not ok 89 - the Read-only plane and the 2-way Edit plane stay byte-identical to the base (#1677):client.editPlane is not a functionAfter the change the same file is 89/89 green (84 before it), and the drawer measures:
The unchanged two-branch plane is a geometric condition, not a branch count: as long as a two-branch graph's fitted cards stay apart, its 4px gap leaves the last pixel of the out-port dot under the next card exactly as before (the dot's centre is free, and byte-identity is what this issue asks of that plane). A two-branch graph whose stored coordinates are close —
fork2-stored, x=2000/2017 — already overlaps on the base (1 pair, 166×72, r2 drawn over r1's port centre) and is laid out here: wrapped, 0 overlaps. So read the guarantee as "two branches whose fitted cards do not overlap", not as "two branches".The issue's six-line reproduction still prints exactly its six lines: it measures
fitPlane, which this change deliberately leaves alone — that is what keeps the two-branch plane byte-identical. The byte-identity is pinned in the test as strings captured from base1db1037a:edit:delivery@364,edit:fork2@364,read:delivery@368,read:fork3@368,read:fork4@368,read:fork6@368.Ran at this tip:
TZ=UTC ARCH_DOCS_BASE=6a33d0eb npm run verify→ exit 0;cd plugins/workflow && node --import ./test/resolve.mjs --test test/client.test.js→ 89/89. The same file with only the baseplugins/workflow/client.jsin place is 5 red at base6a33d0ebwith the identical numbers listed above. Not run: the smoke test (nocore/index.jsorsrc/host/change), and no browser — this session has none, so the geometry is asserted on the props the plane renders.core/test/room-external.test.js#198 (a child-process timeout) failed in two of the full runs and is green alone (13/13) and in the final run: the known flake, untouched by this diff.One behaviour to know
In a laid-out plane the rows come from
layers, so a card dropped there returns to its row slot on the next paint. The drag also writes panel coordinates back as the node's storedx/y: the gesture starts fromspot.x/spot.y(panel coordinates,scale:1and no offset) atclient.js:1191, adds a plain delta at:1105, and:1111commits that value. A stored node at{-188,108}dragged in the wrapped plane becomes{82,153}in the saved graph, and the Settings canvas — which draws the stored coordinates — then shows it at the panel position; a palette item dropped into the wrapped plane lands the same way beforeflowLayoutputs it in its own row. That write-back is#1686, separate from this change.Checkpoint
{ "pr": 1683, "claim": "Dev", "issue": 1677, "summary": "The drawer's Edit plane now keeps a parallel step's cards apart. While a parallel layer's fitted cards stay apart nothing moves; when they would overlap, the plane lays the graph out in rows with the Read-only plane's column width and wrap, so every branch's out-port can start a wire. A two-branch graph stays the fitted plane, and the Read-only plane is unchanged, byte for byte against base 1db1037a — while that graph's fitted cards do not overlap; a two-branch graph whose stored coordinates sit close becomes laid out like any other (see below).", "files": ["plugins/workflow/client.js", "plugins/workflow/test/client.test.js", "docs/subsystems/workflow.md", "changelog.d/1677-drawer-edit-overlap.fixed.md"], "checks": { "ran": "TZ=UTC ARCH_DOCS_BASE=6a33d0eb npm run verify", "result": "green", "at": "5119515bf28da3829e8acf1bf40d0046ef6e238b" }, "next": "review at this tip" }