WM_POINTERENTER is sent, not posted, so only WH_CALLWNDPROC sees it; it
now reads the pen end like an update, so a pen held still after entering
range on its eraser end selects the Eraser.
A contact's end is kept past WM_POINTERLEAVE until the UI reads it once
(take_pen_end): an eraser-end tap and the pen leaving range, all handled
before the next frame, now erase instead of using the previous tool.
The pointer hooks read PEN_FLAG_INVERTED from GetPointerPenInfo and
report the pen end through Services::pen_end, so flipping the pen
switches to the Eraser and the tip restores the previous tool, as on
macOS. A WH_CALLWNDPROC hook beside WH_GETMESSAGE catches
WM_POINTERLEAVE, which Windows documents as sent, not posted.
PEN_FLAG_ERASER alone is an eraser button on the barrel and does not
switch tools.
* Add an opt-in WinTab backend for pen pressure on Windows
Windows Ink stays the default. Preferences > Tools > Pen Tablet has a Tablet
input dropdown (Windows Ink (default) / WinTab). WinTab opens a WinTab 1.4
system context on PhotoCraft's window and polls pressure and the eraser end
(tilt on devices that report orientation axes; rotation only with a pen and
driver that report twist) into the stylus feed. The row says to turn Windows
Ink off in the tablet's software utility; the choice applies at next launch.
- crates/tablet: Windows-only wintab/wintab-sys backend. Devices with
orientation axes use the orientation packet; pressure-only devices open a
packet without it and report neutral tilt. Leaving is the driver's hardware
proximity message (WT_PROXIMITY) and the packet's out-of-context status, with
a long fallback for drivers that never report either. Overlap priority
follows window focus, and the message hook requests a frame for each WinTab
message so pressure-only strokes update without cursor movement.
- apps/photocraft: install the backend when the preference is on; poll it at
the start of each frame; the installed wake repaints the UI.
- ui-egui: TabletPollFn service; the Windows-only Pen Tablet row with the
Tablet input dropdown and the note.
- engine: tools.tabletInput (windowsInk/winTab), default windowsInk.
- docs: hardware-parity WinTab gap entry, qualifying tilt to orientation axes
and rotation to twist-reporting pens.
Tested locally on a Wacom tablet with Windows Ink off: pressure, tilt and the
eraser end reach the brush (rotation where the pen reports twist); the default
path is unchanged.
* WinTab: a message that finds the state borrowed is skipped, not a panic in the hook
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WinTab: rustfmt
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Scorecard: count the Tablet input setting
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: FredApps <153173854+FredApps@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
On Windows with Windows Ink (WM_POINTER), winit drops penFlags (PEN_FLAG_BARREL) and reports stylus contact as WindowEvent::Touch, which egui-winit maps exclusively to PointerButton::Primary. Additionally, Windows Ink does not update GetAsyncKeyState(VK_RBUTTON) when pressing the pen barrel button. Consequently, Alt + Barrel Button drag was recognized as Alt + Left Drag (triggering the eyedropper and painting strokes instead of brush resize), and right-clicks with the stylus were treated as left-clicks.
This commit resolves the issue by:
1. Adding a native Windows message hook (WH_GETMESSAGE) in crates/tablet/src/windows.rs calling GetPointerPenInfo to intercept PEN_FLAG_BARREL (0x00000001) and POINTER_FLAG_SECONDBUTTON.
2. Exposing
ight_button_down in Services combining the pointer hook and GetAsyncKeyState(VK_RBUTTON).
3. Updating canvas.rs and paint_mouse.rs to prevent strokes_live and alt_eyedropper from hijacking the stylus gesture when the barrel button is held, and correctly routing resize events.
4. Adding tests asserting that Alt + stylus barrel drag resizes diameter horizontally and adjusts hardness vertically without triggering eyedropper or painting.
monitor_macos is harness = false, so nothing answered cargo-nextest's
discovery: `--list --format terse` ran the whole test and nextest failed
to parse its output on macOS. List the one test, and nothing for
`--ignored`, as mac_menu_appkit already does; `monitor_macos --exact`
still runs the body.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Wayland compositors give a pen only to clients that bind zwp_tablet_v2,
which winit 0.30 doesn't, so on Wayland the pen did nothing in the
window. With a pen attached (BTN_TOOL_PEN in /proc/bus/input/devices),
$DISPLAY set and the X11 libraries installed, the window now opens
through Xwayland, where the X11 reader gets pressure, tilt and the
eraser. PHOTOCRAFT_NATIVE_WAYLAND=1 keeps native Wayland.
macOS: the AppKit event monitor was installed before winit created the
shared NSApplication; it now goes in from eframe's app creation. The
pen's button-up (pressure 0) no longer zeroes the pressure of the
stroke's last moves, which reach the UI in the same frame.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
RickiNano
aiongg
Dylan M. Taylor
skylar taylor-barrick
Anim86
IvanandClaude Opus 5.5
BFlatandClaude Opus 5.5
Brandon Thomas