Widget pointer inventory

Every file under crates/teksilo-widgets/src/ that carries pointer, gesture or hover code, with the touch-migration package that owned it. This was the checklist the control sweeps sized themselves from; it is now closed — every row is either migrated with a named test or carries a written no-change reason, and no row says "pending".

Two conventions, because the WCAG sweep and the target-conformance harness read this file:

• a row cites file + function, never file + line: re-derived across this programme, a file:line citation in an artifact rotted almost completely within a few packages;
• "no change needed" is a claim about the code, so it names what was measured or which existing test already covers it. A row that merely reads plausibly is a defect handed to two downstream packages.

Scope and method

A file is in scope if, outside #[cfg(test)] blocks, files named tests.rs, and comment lines, it mentions any of:

on_pointer_event · PointerDown / PointerUp / PointerMove / PointerEnter / PointerLeave · on_tap · on_double_tap · on_triple_tap · on_long_press · on_drag* / on_drop · on_swipe · on_hover · on_scroll · capture_pointer · hover_within · start_drag

Two supplementary markers, DragPhase and TapEvent, catch handler bodies factored into a helper file that never names the builder method. Exactly one file is reached only that way: grid_view/selection.rs, which builds the GridView marquee closure. Marker columns show the supplementary two in italics.

# reproduce the file list
cd crates/teksilo-widgets/src
grep -rlnE 'on_pointer_event|Pointer(Down|Up|Move|Enter|Leave)|on_tap|on_double_tap|on_triple_tap|on_long_press|on_drag|on_drop|on_swipe|on_hover|on_scroll|capture_pointer|hover_within|start_drag|DragPhase|TapEvent' \
  --include=*.rs . | grep -v tests.rs | sort

(The published table applies the comment and #[cfg(test)] filters the bare grep cannot; the raw grep over-reports by five files whose only mentions are in prose — tree_view.rs, rich_text/context_menu.rs, rich_text/frame_loop.rs, toast/registry.rs, grid_view/layout/strategy.rs — plus styles/recipe_tab_style.rs, table_view/imperative.rs and tree_view/builder.rs. Those eight are listed at the end under "Prose-only mentions".)

Result

78 files carry real pointer code. Every one now has a verdict:

The five files the first pass found unclaimed are settled: combo_box.rs and snackbar.rs went to P25 (the clause named both), avatar.rs and primitives/text_widget.rs to P24, and primitives/dead_zone.rs was reviewed under the arbitration package and kept as it was. Their rows say so.

P31 claims no file in this crate. drag_preview.rs has no pointer handler (it is a paint-only overlay), and drop_target.rs — which the work breakdown named in both places — is P25's, which is where its row sits.

splitter/handle.rs is named by both P29 (its 400 ms dwell reveal) and P30 (its grab geometry). Its pointer code — the Ignored-on-press / capture_pointer-on-move latch — belongs to P30, so that is its verdict; the dwell reveal is row 2 of the hover census and was P29's.

The files the first pass left unclaimed

Nine files carried real pointer code that the work breakdown assigned to nobody. Four of them were the largest single omission in the plan: list_view/body_pane.rs was claimed by P23, but its four siblings were not, and all five implement the same press-time row selection, tap/double-tap activation and start_drag reorder that P23 exists to convert. P23 took all four. The remaining five are settled too, each by the package whose clause named it:

Release-time commits in the five body panes — guarded under P22

The five panes stay P23's to convert, but one class of defect in them was reachable the moment P22 gave the data views a pan, so P22 fixed it rather than leaving it to a later package.

A row body commits things on PointerUp from a raw on_pointer_event arm, not from a gesture: TreeView's chevron toggle, and the deferred collapse of a multi-selection in TreeView / ListView / TableView / TreeTableView (GridView's is the same shared deferred_select::on_up). The arbitration cannot stop a raw arm — a won pan claim is not an active_drag, so the release is not routed to handle_drag_drop — and the row is not reliably a sequence member either (it is enrolled only when it carries a drag), so it cannot count on being told it lost. Measured before the fix: a 120 dp finger pan over 200 collapsed branch rows scrolled the tree and expanded the row it started on (visible_count 200 → 201); a short pan on a fully-selected view collapsed the selection to that one row. Each commit now asks data_views::release_completes_the_press (which reads EventContext::press_is_inside). Covered by question 5 of crates/teksilo-widgets/tests/scrollables_touch.rs.

Closed since, against grid_view.rs: a finger did not scroll a GridView whose selection is in SelectionMode::Multi. The cause was neither the claim losing the arbitration nor the marquee running instead — both had been ruled out, and an early draft that blamed a slop race was wrong. It was the capture dispatch: in Multi mode the rubber-band marquee's on_drag sat on the GridView's own node, the one carrying the PanClaim, which gave that node a gesture arena and so the implicit press capture. The router dispatches a move to the captor before it advances the arbitration, so the marquee's DragRecognizer latched at drag_slop (18 dp) and decided the sequence on the first sample — after which the candidate walk yields nothing, the claim is never evaluated at pan_slop (36 dp), and no Scroll is synthesised at all. The marquee then declined the press for landing on a tile. The drag won and did nothing, which is exactly what the trace showed.

The fix has two halves, each with its own test in crates/teksilo-widgets/tests/data_view_drag.rs: the body pane takes a no-op tap (data_views::press_absorber) so the press is captured inside the claimant rather than by it, and the marquee's drag moves onto a data_views::DragSurface that strictly encloses the pane — the only shape the tree arms DragActivation for, so a finger's marquee now waits for a long press while a mouse still latches at 5 dp. a_finger_on_a_multi_select_grid_pans_it in scrollables_touch.rs is no longer #[ignore]d.

Two further files were swept in by the marker set but genuinely need no change: list_source.rs and tree_source.rs, whose on_drag_out(k) is a data-source policy callback with no pointer plumbing behind it.

Inventory

Prose-only mentions

These eight files match the marker grep but only inside doc comments or // commentary. They carry no pointer handler and are out of scope; they are listed so a later reader running the bare grep does not think they were missed.

Files named by a package that carry no pointer code

The work breakdown names these; none of them has a pointer handler today, so they appear in no row above. Recorded so the sweeps do not go looking.

badge.rs · color_edit.rs · common/scroll.rs · date_edit.rs · date_range_edit.rs · date_time_edit.rs · drag_preview.rs · file_picker_field.rs · hex_color_input.rs · icon_button.rs · menu_list.rs · time_edit.rs · title_bar/window_frame.rs · toolbar.rs · tree_view.rs

color_edit.rs is one of these and was named by P25's own clause: it carries no pointer handler at all — its swatch, its hex field and its picker popover are each their own widget with their own row — so there was nothing in it to migrate.

common/drag_autoscroll.rs now exists: P23 created it by hoisting the five duplicated EDGE / MAX_VELOCITY pairs listed in the density inventory §3b.

What P25 did not do, and why

Two things the clause or an earlier artifact asked for are refused, each with the measurement that justifies it. Both are recorded so a later reader does not take them for oversights.

1. The SplitButton chevron is not partitioned. The density inventory promised "hit via partition_targets with a 24 dp floor"; the two halves are separate nodes with a hairline divider between them, so a partition would have had to move the painted boundary — at Compact, against the programme invariant. A kind-gated hit_outset on the chevron delivers the same floor and leaves a mouse's boundary exactly where it is drawn.
2. A tab's label and its close button are not partitioned either. The clause asked for "tab label/close through partition_targets + target_regions"; the close affordance is a real IconButton node at IconButtonSize::Compact — 24 dp at Compact and on the ladder above it — so there is no in-node split to carve, and tab_widget/header.rs's own touch section says so. The reveal problem it does have (hover-only, invisible to a finger) is the hover census's and was answered by RevealPolicy.

And one deliberate limit: docking/activity_bar.rs's rail item extent stays un-projected. See the P25 entry in the density inventory's corrections for the measurement.