Skip to content

fix(pointer): add per-waypoint click, redraw the hand and fist, make outline visible - #442

Merged
LeadcodeDev merged 2 commits into
mainfrom
fix/pointer-waypoints-and-glyphs
Sep 29, 2026
Merged

LeadcodeDev merged 2 commits into
mainfrom
fix/pointer-waypoints-and-glyphs

Conversation

@LeadcodeDev

Copy link
Copy Markdown
Owner

Closes #433. Part of #438.

Waypoints without a click. A path waypoint clicked on arrival with no way to
opt out, so a pointer could not round a corner on its way to the control a
walkthrough is about. CursorWaypoint gains click, defaulting to true, so
every scenario written before it renders identically. click_at stays ignored
while a path is present — clicks_come_from_the_waypoints_when_a_path_is_given
pins that contract, and a first attempt at chaining the two turned it red. A
pointer that should click somewhere says so on the waypoint.

The glyphs. The hand was an open heptagon plus a detached triangle; the fist
was a bare heptagon. The polygon was never the real limit — add_contour only
emits line_to, so no sequence of points was going to read as a hand.
add_smooth_contour runs a quadratic through the midpoint of each edge, and that
is what turned a blob into a palm. The arrow keeps its hard corners.

The finger also had to survive the glyph's own outline stroke. At size * 0.07
centred on the path it eats size * 0.035 inward on each side, so a finger 14 px
wide in the polygon painted 6 px of fill — measured, after three iterations that
each looked right in the source and wrong in the frame. A blunt tip rather than a
tapered one is what finger_probe was already asking for at (0.08, 0.05).

tone: "outline". A white stroke over a transparent fill, so on a white frame
it was invisible — while its own doc comment promised it reads on any background.
Making the code match the promise beat deleting the promise: the glyph now carries
a dark contour under the white one. Declaring outline_color turns the contour
off, since at that point you have said what the edge should be.

Tests

a_waypoint_can_be_passed_through_without_clicking,
a_waypoint_clicks_by_default_so_an_existing_scenario_is_unchanged,
opting_every_waypoint_out_leaves_a_pointer_that_travels_and_never_clicks, and
an_outline_pointer_carries_a_dark_contour_so_it_reads_on_a_light_frame, which
scans the whole frame for the darkest painted channel.

The existing hand_glyph_closes_into_a_grab_during_a_click_and_reopens_after and
finger_probe_is_inside_the_open_hand_but_outside_the_closed_fist both constrain
the redraw and both stayed green.

cargo test -p rustmotion-components --lib pointer 19 passed. Clippy and the full
suite run at integration — two sibling workstreams are mid-flight in this checkout.

The default H.264 branch pushed -profile:v high10 -pix_fmt yuv420p10le
with no gate at all, so every render without --hardware-acceleration
produced a High 10 file. QuickTime and Safari refuse those outright, and
a user reported exactly that: a file the tool had just written and they
could not open.

The default is now -profile:v high -pix_fmt yuv420p. The old encode is
still reachable as --codec h264_10bit, which is the same libx264 call
with the same crf and preset.

Making it a codec name rather than a new flag means it travels the
plumbing that already exists: codec: &str already reaches ffmpeg_args
from nine call sites, so nothing needed a new parameter. check_codec's
allow-list and containers_for both had to learn the name -- the first
rejected it before ffmpeg_args ever saw it, which is how the first
attempt silently produced an 8-bit file for --codec h264_10bit.

Verified end to end with ffprobe: the default gives h264/High/yuv420p,
--codec h264_10bit gives h264/High 10/yuv420p10le.

The docs claimed 10-bit as the default in five places -- README, CLAUDE,
SKILL, and rules/gradient-quality.md -- and recommended ProRes for dark
gradients without mentioning that 10-bit H.264 was already on. All four
now say which of the two trades away playback and why.

Refs #435
…outline visible

A path waypoint clicked on arrival with no way to opt out, so a pointer
could not round a corner on its way to the control a walkthrough is
about. CursorWaypoint gains `click`, defaulting to true, so every
scenario written before it is unchanged. click_at stays ignored while a
path is present: an existing test pins that contract, and a first
attempt at chaining the two turned it red.

The hand was an open heptagon plus a detached triangle and the fist was
a bare heptagon. Both are single smoothed outlines now. The polygon was
never the real limit -- add_contour only emits line_to, so no sequence
of points was going to read as a hand. add_smooth_contour runs a
quadratic through the midpoint of each edge, which is what turned a
blob into a palm. The arrow keeps its hard corners.

The finger also had to survive the glyph's own outline stroke: at
size * 0.07 centred on the path it eats size * 0.035 inward on each
side, so a finger that looked 14px wide in the polygon painted 6px of
fill. A blunt tip rather than a tapered one is what the existing
finger_probe test was already asking for, measured at (0.08, 0.05).

tone: "outline" is a white stroke over a transparent fill, so on a white
frame it was invisible -- while its own doc comment promised it reads on
any background. It now carries a dark contour under the white one.
Declaring outline_color turns the contour off, since at that point you
have said what the edge should be.

Closes #433
@LeadcodeDev LeadcodeDev added the bug Something isn't working label Sep 29, 2026
@LeadcodeDev LeadcodeDev self-assigned this Sep 29, 2026
@LeadcodeDev
LeadcodeDev merged commit 51546a0 into main Sep 29, 2026
4 checks passed
@LeadcodeDev
LeadcodeDev deleted the fix/pointer-waypoints-and-glyphs branch September 29, 2026 13:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Pointer: waypoints without a click, readable hand/grab glyphs

1 participant