CI Build Failure Analysis

Hey @aethersdr-agent[bot] — thanks for tackling #1668, this is a great approach to avoid the NSResponder chain corruption!

What failed

Both the build and analyze (cpp) jobs failed at the Build step. The root cause is a constructor ambiguity in PanFloatingWindow.

The problem

The PR adds a new constructor overload:

explicit PanFloatingWindow(QWidget* parent = nullptr);  // NEW

alongside the existing one:

PanFloatingWindow(PanadapterApplet* applet, QWidget* parent = nullptr);  // EXISTING

Then in PanadapterStack.cpp, the call:

auto* fw = new PanFloatingWindow(nullptr);

is ambiguous — the compiler can't decide whether nullptr is a QWidget* (matching the new constructor) or a PanadapterApplet* (matching the existing constructor's first parameter, with parent defaulting to nullptr). Both are equally valid implicit conversions from std::nullptr_t.

How to fix

Option A — Use an explicit cast at the call site:

auto* fw = new PanFloatingWindow(static_cast<QWidget*>(nullptr));

Option B (cleaner) — Remove the default value from the new constructor's parameter, since you're always calling it with an explicit nullptr anyway:

explicit PanFloatingWindow(QWidget* parent);  // no default

This eliminates the ambiguity entirely and makes the intent clear.

Not your fault

The logic of the fix (avoiding the transient top-level NSWindow by reparenting directly via adoptApplet()) looks correct and well-reasoned. This is just a C++ overload resolution edge case. The analyze (cpp) / CodeQL failure is a cascading consequence of the same build error — once the build compiles, CodeQL will pass too.

Keep up the great work! 🎙️