fix(gui): guard TMate2Overlay calls in applyFlexControlWheelAction with HAVE_HIDAPI

[NF0T]

Summary

Fixes #3435.

applyFlexControlWheelAction is declared outside any #ifdef HAVE_HIDAPI block
(it handles wheel inputs from FlexControl, MIDI, and other non-HID sources), but
PR #3401 added five call sites inside it that reference triggerTMate2Overlay(TMate2Overlay::...).
Both the TMate2Overlay enum class and triggerTMate2Overlay are declared inside
the #ifdef HAVE_HIDAPI block in MainWindow.h (lines 573–623), so they are
invisible to the compiler on configurations without HIDAPI — specifically the
MinGW / no-setup-hidapi.ps1 Windows developer build.

Affected actions: WheelRit, WheelVolume, WheelHeadphoneVolume,
WheelPower, WheelCwSpeed — all five call sites are wrapped with
#ifdef HAVE_HIDAPI / #endif. Runtime behavior on HIDAPI-enabled builds
is unchanged.

This is the same guard pattern applied in PR #3344 to UlanziDial.

Constitution principle honored

Principle IX — Surface Only What Survives. Code on main must compile on
all target platforms. The no-HIDAPI MinGW path is a required target
(Windows developer builds before running setup-hidapi.ps1); surfaces that
break that build do not survive the platform gate.

Test plan

• Build without HAVE_HIDAPI passes — MinGW GCC 13.1.0 / Qt 6.11.0 / no hidapi, verified locally
• Build with HAVE_HIDAPI unaffected — same toolchain, guards compile out cleanly
• Existing tests pass (CI)

Checklist

• Commits are signed (docs/COMMIT-SIGNING.md)
• No new flat-key AppSettings calls — N/A
• All meter UI uses MeterSmoother — N/A
• Documentation updated if user-visible behavior changed — no user-visible change
• Security-sensitive changes reference a GHSA if applicable — N/A

[aethersdr-agent]

Hi @NF0T — thanks for this. The failing check is Qt Accessibility Static Analysis, but it's a CI infrastructure bug in .github/workflows/a11y-check.yml, not your code. Your #ifdef HAVE_HIDAPI guards in src/gui/MainWindow.cpp look fine and have nothing to do with accessibility.

What's actually failing

The workflow's "Run accessibility check" step fails on PRs that touch src/gui/ and produce zero findings. The culprit is this line in .github/workflows/a11y-check.yml:43:

COUNT=$(grep -c "^::warning" /tmp/a11y_output.txt || echo "0")

When grep -c finds zero matches, it prints 0 to stdout and exits with status 1. The || echo "0" then runs as well, so $COUNT ends up being a two-line string: "0\n0". The next line then writes:

findings=0
0

…to $GITHUB_OUTPUT, which is malformed (the lone 0 isn't key=value) and the runner errors out the step.

I reproduced this locally against your branch's MainWindow.cpp:

$ COUNT=$(grep -c "^::warning" /tmp/a11y_output.txt || echo "0")
$ echo "COUNT=[$COUNT]"
COUNT=[0
0]

The script itself (tools/check_a11y.py) found 0 findings on your file — the failure is purely a shell-quoting bug in the workflow wrapper.

Why your PR is the trigger

The a11y workflow was added in #3289 and is fairly new. Most PRs don't touch src/gui/ so the workflow skips entirely. PRs that do touch src/gui/ and produce ≥1 warning go down a different branch and avoid this code path. Yours is the unfortunate combination: touches src/gui/, produces 0 findings, hits the bug.

What to do

Nothing on your end. Per the workflow's own comments and the check_a11y.py docstring, this check is "warnings only — the build is not blocked" — it's not a merge gate. A maintainer can either:

1. Fix the workflow (e.g. COUNT=$(grep -c "^::warning" /tmp/a11y_output.txt) || COUNT=0), or
2. Merge once the remaining checks (build, check-macos, check-windows, analyze) pass — those are still in progress as of this comment.

The actual change in this PR (gating triggerTMate2Overlay calls on HAVE_HIDAPI) is exactly the kind of small, surgical fix the project benefits from. Thanks for chasing it.

---

_{🤖 aethersdr-agent · cost: $15.9898 · model: claude-opus-4-7}

[svabi79]

Thanks for catching and fixing this so fast, @NF0T — this one's on me. I added those five triggerTMate2Overlay(...) calls into applyFlexControlWheelAction in #3401 without checking that the function lives outside the HAVE_HIDAPI guard while the overlay enum + helper are HIDAPI-only. CI builds with hidapi, so the no-HIDAPI MinGW path that actually breaks never got exercised on the PR — a gap I should have reasoned about rather than relied on green checks for.

Your guard placement is exactly right and matches the #3344 UlanziDial pattern; runtime behaviour on HIDAPI builds is unchanged. Reviewed the diff — LGTM. Sorry for the cleanup, and thanks again.

73, Jan (svabi79)

[ten9876]

Rebased onto current main as `f232c3cb` to pick up #3442's a11y workflow fix. Your code didn't trigger any a11y findings — same workflow-yaml bug that hit your #3439: the pre-#3442 step crashed writing the zero-findings result to `$GITHUB_OUTPUT`, even though the lint itself completed cleanly. Timing: CI ran 2026-06-06 19:31 UTC, #3442 merged 21:44 UTC.

No content changes to your fix — the `HAVE_HIDAPI` guards around the `TMate2Overlay` calls in `applyFlexControlWheelAction` are exactly as you wrote them. CI will re-run against `f232c3cb` and the a11y check will pass cleanly this time.

Principle XI.