Repository navigation
Fix pen not activating apps and pen/eraser not switching after clicking in - #6
Merged
Merged
Conversation
Clicking into a background app with the pen raised its window but never made it the active app. macOS only delivers tablet proximity events to the frontmost app, so the app never learned the pointer type: it either ignored pen input or kept a stale tool (the eraser end still drew). - On each tip/eraser press over a normal window of a non-frontmost app, activate that app via Accessibility (kAXFrontmostAttribute), falling back to NSRunningApplication.activate(). Synthesized clicks raise the window but macOS does not let them activate the app. - Re-send proximity-enter with the current pointer type when the frontmost app changes, and when the pen end changes without a reported exit. - Create all events from an HID-system-state CGEventSource (with local event suppression disabled) so they are tagged like hardware input rather than as synthetic session events. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
After clicking into Clip Studio Paint with the pen:
Cause
A pen tap raised Clip Studio's window but never made it the active app. A listen-only event tap showed the terminal staying frontmost through the whole pen session. Clip Studio only became active, for about 12ms, on the next trackpad click. macOS delivers tablet proximity events (which carry whether the pen tip or the eraser is in range) only to the frontmost app, so Clip Studio never received them. Qt apps look up the tool by the device ID from the last proximity event, so Clip Studio either didn't recognise the pen or kept a stale tool.
Comparing a trackpad click with a nib click field by field showed nib's events had no source state (synthetic), no event number, no hardware sender ID, and nib's PID as source. Giving them an HID-state source alone didn't let the click activate the app.
Fix
main.swift): on each tip or eraser press over a normal window (layer 0) of a non-frontmost app, nib activates that app by settingkAXFrontmostAttributethrough Accessibility, with a 0.25s AX timeout. If that fails it falls back toNSRunningApplication.activate(). The menu bar, Dock, panels and overlays are left alone. This goes throughEventEmitter.willPress.EventEmitter): when the frontmost app changes (NSWorkspace.didActivateApplicationNotification), nib re-sends proximity-enter with the current pointer type. It also does this when the pen end changes without a reported exit.EventEmitter,TouchGesture): events now carrysourceStateID = 1like hardware input, with local event suppression disabled so the keyboard isn't muted after posting.Testing
swift test: 47 tests pass. 4 new: proximity re-announce, re-announce on flip in range,willPressfires once per press, HID source state.🤖 Generated with Claude Code