Let the mouse draw, on the tools rather than the gestures

[marcosqlbi]

Someone who downloaded a whiteboard onto a laptop with no pen and no touchscreen found that the toolbar did nothing. 1.1 conceded that at startup and collected votes in discussion 78. This answers it, as 1.2.0.

Mouse drawing is a setting — Off / On / WhenNoDigitizer, defaulting to the last — under which the left button does what the selected tool does. One rule governs it and any later change to it: a mouse gets the tools, not the gestures. Everything on the toolbar becomes reachable, and nothing that exists because of what a hand and a pen can do — pressure, hover, the reverse end, the barrel button — is simulated with modifiers and timers.

Ctrl is the old mouse: it selects, moves and resizes a container and hands the drawing tool back, which is what the left button did on its own. Ctrl takes double-click framing with it, because two quick dabs with an ink tool are two strokes and the click count is tested before the tool branch. The tool otherwise stops being handed back after every gesture, including a right-button pan, which would have taken someone who chose the Eraser and quietly left them holding a pen.

Pressure is the neutral constant the straight-line constraint already draws at. Deriving it from speed was rejected: the width would vary for a reason the hand cannot feel. Calligraphy is unaffected, since its width comes from speed rather than pressure, and the highlighter already ignores pressure.

Why this is small

Decision 22. AppendInkPoint — renamed from AppendPenInkPoint, which is all it needed — takes a screen point and a pressure and has no idea what device it is serving, so the mouse gets the straight-line constraint and the calligraphy dynamics without a second implementation. PointerAction.Erase was already written and unreachable from the mouse.

Not one line of the pen path changed, which was the condition for building it at all: every mouse handler already returned early on a non-null StylusDevice. Mouse drawing can therefore be left on beside a pen, which is why On is offered and not only the automatic default.

Reviewing

The proposal, with the alternatives weighed and rejected, is docs/mouse-mode.md; the settled form is decision 23. Worth a look in review:

• InkSurface_PreviewMouseDown and BeginMouseAction — the branch order, and that borrowSelect reproduces today's behaviour exactly when the setting is off.
• CompleteMouseAction releases the capture itself, which fires LostMouseCapture synchronously mid-decision; that path returns early rather than clearing _mouseToolBorrowed out from under it.
• EndMouseInk nudges a stationary stroke, because two coincident points enclose nothing to render and a click would otherwise draw nothing where a pen tap draws a dot.

Verification

Build is clean and the Core smoke tests pass, including the settings round-trip and the version 12 → 13 upgrade. Those tests are UI-free, so the behaviour itself is not covered by them — the nine-step checklist added to the README under "Mouse drawing validation" has not been walked. Step 9 is the one that matters: on a pen machine with Mouse drawing On, draw with the pen and confirm nothing about it changed.

🤖 Generated with Claude Code