mirror of
https://github.com/storytold/pdfcraft.git
synced 2026-10-27 03:27:21 -06:00
The page view had no single reading of the pointer. About twenty page modules each read egui's raw state (hover_pos, latest_pos, interact_pos, press_origin) and tested it against an unclipped page rectangle. That state knows nothing of what is drawn over the pages, and hover_pos is None on the frame a finger or a Windows pen lifts: egui-winit sends PointerGone with every touch release, and winit reports Windows pen input as touch. So a tap placed no stamp, followed no link and ticked no check box. A touch drag of a comment never committed, and the next drag anywhere on the page moved the comment. The Stamp crosshair showed on the command palette, on the quick bar and on the chrome over a page scrolled under it, a link's tip floated over the Unlock prompt, and a double-click on a dialog's backdrop selected the word under it. canvas::document_area now reads one PagePointer per frame from the pages' content widget (step 1 of the page pointer router in the cursor-handling review): - pos: interact_pos, which keeps the position through a touch release, only while egui has the pages under the pointer with nothing over them (contains_pointer, and the top layer there is the pages', as the closed #2626 did) or while the pages hold a press. - origin: where the held press began, also on the frame that brings both the press and its release. This replaces the text layer's raw-event fallback (#2100). - edges: the frame's primary presses and releases on the pages, in order. It reaches the page modules through comments::PageCx and as an argument: the stamp blocks, text layer, page press and link and comment hover in canvas.rs; comments and the signature drag preview; forms and Prepare a form; Fill & Sign and the Sign area; crop, marquee zoom, snapshot, camera and measure; redact and the Link tool; added content, Edit text, images and objects. page_covered, a hand-kept list of what covers the pages that missed the Unlock prompt, is gone. The pages' hover tip is click-through, as a tooltip is, so a quick move onto it does not take the pointer off the link under it. Tests: tests/it/support/input.rs sends pointer input in the frames the platform delivers it in (a touch tap and drag, a click in one frame, a double-click). kittest otherwise runs one frame per event, so the suite never saw a touch release. tests/it/pointer.rs holds the review's probes and #2626's layer tests. With the fix reverted, the tap (stamp, link, check box), touch drag, palette, quick bar, chrome, Unlock tip and dialog double-click tests fail, and the mouse-click and one-frame-click controls pass. The tip test fails with the tip interactable, and each page_pointer unit test fails under a mutation of the part it pins. The probes for later steps stay ignored: the link hand and the I-beam over other tools' targets (step 2), paragraph edges (step 3) and Escape mid-drag (step 4). touch_tap_ticks_a_check_box is ignored until the check box focus fix that follows: since #2223 a tap on a check box counts as a click away from its focus. tests/it/comments.rs: the multiline markup hover test (#3541) hovered a point below the window on a page rotated 270 degrees, and its tip showed only because the hover was tested against the page's whole rectangle. Its harness now zooms to 100 %, so every rotation shows the whole page, and the hover helper asserts the point is on screen. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>