feat(notch): trackpad gestures, Space-swipe collapse, and motion/appearance controls - #314

Thanks for this — the engineering standard is high, and the parts of it I want are things I'd have never got to on my own. I merged it locally onto current main (which has moved: #315, #319, #322, #323, #325, #326, #329 all landed today) and it builds clean with 990 tests green, so nothing below is about it not working. It's about what I can't take responsibility for shipping in one piece.

Requesting changes with a concrete split at the bottom.

1. There are two private-API surfaces, and only one of them is flagged

The PR calls out MultitouchSupport, and that one I'm actually fairly comfortable with — dlopen/dlsym, a 96-byte stride check before any field is read, isAvailable going false, and the activeSpaceDidChange observer still there as the fallback. That is the right way to do it.

AllSpacesAnchor.swift is not mentioned anywhere in the description, and it's the riskier of the two:

@_silgen_name("CGSSpaceCreate")
private func CGSSpaceCreate(_ cid: CGSConnectionID, _ options: Int, _ properties: NSDictionary?) -> CGSSpaceID

Seven undocumented CGS symbols, bound by @_silgen_name, called unconditionally from a singleton init at launch. There is no isAvailable, no degradation path, and no way for it to fail softly: a missing or renamed symbol is a dyld failure, and a changed signature is undefined behaviour, not a caught error. CodeIsland currently has zero private-API dependencies (grep -rn '_silgen_name\|dlopen\|PrivateFrameworks' Sources/ is empty on main), ships notarized and auto-updates via Sparkle — so the blast radius of getting this wrong is every installed copy failing to launch after an OS update, with no way for me to reach those users.

If the anchor is genuinely load-bearing for the swipe behaviour, it needs the same treatment MultitouchDevice got: resolve through dlopen/dlsym, verify every symbol, and fall back to plain collectionBehavior when any is missing. deinit on a static let shared also never runs, so the space it creates is there for the process lifetime regardless.

2. The rationale for the window changes doesn't match this codebase

PanelWindowBehavior.collectionBehavior is byte-identical to what PanelWindowController already passed:

// main, before this PR
panel.collectionBehavior = [.canJoinAllSpaces, .fullScreenAuxiliary, .stationary, .ignoresCycle]

but its doc comment explains that .canJoinAllSpaces and .managed are contradictory "which is what caused the island to drop out and reappear mid-swipe". .managed has never been in that set. So the comment diagnoses a bug that isn't in this code, and the "fix" is a reordering of the same four flags — which means whatever was actually causing the mid-swipe behaviour you saw is still unexplained, and I don't know which of the other changes in this area is the one doing the work.

Related, and the reason I can't just wave it through: the style mask gains .utilityWindow and .hudWindow because it "matches a reference notch-overlay panel's style mask". I don't take code or structure from other notch apps — licensing, and I'd rather this project's decisions be ones I can defend on their own terms. If those two flags earn their place, I need the reason in terms of what CodeIsland's panel does.

panel.isMovable = false I'll take on its own merits; that one's well argued.

3. Two behaviour changes that shouldn't ride along

The close spring changes timing. NotchAnimationMetrics.baseCloseResponse = baseOpenResponse makes it 0.42; it is 0.38 on main, and deliberately so — the close is critically damped at 0.38 / 1.0 specifically so NotchPanelShape's bottom edge never overshoots out from under the notch. I wrote that reasoning up on #298 last month. A speed slider is a great answer to #298; silently retuning the curve it scales is not, and at 0.5× the overshoot risk is where it'd actually show.

Hover-open goes from unconditional to off. openOnHover and hoverOpenDelay are new keys — hover-open isn't a setting today, it's just how the island works. Introducing the setting defaulted off doesn't flip a default, it removes a behaviour every existing user has, and they'd have to find a new checkbox to get it back. I'm open to the argument (brushing past on the way to the menu bar is a real annoyance, and #298's reporter is essentially complaining about the same surface), but that's its own change with its own release note, not a line inside a gestures PR.

What I'd like to do

Split it. Taking these three as separate PRs, in any order, and I'll review them the day they land:

1. Open/close speed slider — NotchAnimationSpeed + the settings row, with baseCloseResponse staying at 0.38. This is the piece I most want; it's a real answer to #298 and it stands entirely alone. The clamp handling UserDefaults.double's 0-for-absent is exactly right.
2. Mascot contrast edge — MascotPalette plus the tint. Opt-in, off by default, geometry untouched, and pulling the signature colours out of MascotsPage's private table so the swatches and the edge can't drift is a genuine improvement on its own. Note main now also has a grok mascot, which you already caught.
3. Gestures on the island — NotchGestureInterpreter, the hitbox, the local+global scroll monitors, the filter cycling. No private API, pure state machine, well tested. My only ask is that hover-open stays as it is and this is purely additive.

That leaves the Spaces-swipe collapse (MultitouchSupport + AllSpacesAnchor + the panel/space plumbing) as its own PR, where we can weigh the private-API question on its own instead of it being the reason three good features wait. For that one I'd want the anchor made optional the way MultitouchDevice already is — or dropped, if the swipe detection works without it.

Also worth knowing before you rebase: #325 refactored ApprovalBar's click-to-jump into a shared startNotchCardJump, so NotchPanelView.swift has moved under you.

Genuinely — the MultitouchSupport write-up, the finger-count preference reading, and catching the two tests that asserted opposite results for the same input (810711a/d0d0d7a) are all better than I'd expect. I want this in; I just need it in pieces I can each say yes to.