serializeResultForTesting used QJsonValue::fromVariant, which cannot
convert the custom LogosResult metatype and silently degraded a
`result`-type return to the literal "null". A QML-only ui_qml plugin
calling a result-returning method through logos.callModule therefore
received null instead of {success, value, error}.
Replace the bespoke serialization with logos-protocol's canonical
logos::qvariantToNlohmann — the same converter every transport
(lp/std/cdylib) already uses. Now ALL types round-trip to QML/JS
identically: scalars as bare literals, containers preserved, integers
kept as integers (QJsonValue::fromVariant degraded them to double),
bytes in the tagged {"_bytes":...} form, and LogosResult as
{success, value, error} (empty error -> null). Fixes both sync
callModule and async callModuleAsync.
Adds test_logos_qml_bridge_result.cpp (regression) plus the
reproduction/isolation harnesses (e2e, gui, handshake, 2-process) built
while proving the long-suspected QML "sequential-call stall" is NOT an
SDK defect: every layer round-trips correctly under isolation, and the
only real bug was this result serialization.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
The ViewModuleHost QtRO peer linked the pre-concurrent-dispatch protocol, so a
c6234940 UI plugin's capability-token handshake was rejected inside it. Align
protocol + SDKs to current master. No source changes (signature-stable API).
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
The out-of-process ui-host (spawned by Basecamp / any app embedding the view
runtime) inherited the parent's process group and had no parent-death cleanup,
so a parent crash could (a) leak a teardown signal into the parent's process
group and (b) leave the host running as an orphan. Mirror logos_host: setsid()
to lead our own group (parent stays foreground/manageable), plus
PR_SET_PDEATHSIG (Linux) + a portable getppid() watchdog so we exit when the
parent dies. Compare against the parent's actual pid (not pid 1) so a parent
that is itself PID 1 (a container) is handled correctly.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Retarget to the qt-split SDK stack (logos-qt-sdk + logos-protocol)
logos-cpp-sdk::logos_sdk no longer exists after the Qt split: the Qt
developer layer (LogosAPI, provider objects) moved to logos-qt-sdk and
the transport/consumer core into the logos-protocol library. Both
targets (the static runtime lib and ui-host) now link
logos-qt-sdk::logos_qt_sdk (which carries logos-protocol transitively)
plus the header-only logos-cpp-sdk::logos_headers.
flake.nix gains logos-protocol/logos-qt-sdk inputs threaded through
nix/{default,test}.nix; the lock pins the extraction-chain branch revs
(temporary — re-lock against masters when the chain merges).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* lock: bump cpp-sdk to the qt-free branch head with the protocol lock fix
This flake declares no follows between logos-cpp-sdk and logos-protocol,
so cpp-sdk's OWN lock governs its nested protocol; b86ff877 still pinned
the P1 protocol rev, which no longer compiles (LogosProviderPlugin moved
in the qt split). 7272c73 carries the corrected pin. Temporary — drop
when the chain merges.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* fix(tests): retarget the unit-test link to the qt-split SDK targets
tests/CMakeLists.txt still linked bare logos_sdk (only built with
LOGOS_VIEW_RUNTIME_BUILD_TESTS=ON, so the package build verified earlier
missed it). The runtime lib's PUBLIC link interface already carries the
qt-sdk/protocol targets; the explicit entries replace the dead archive.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* lock: qt-split chain fully merged — pins advance to masters (cpp-sdk 87abcd8, protocol 9de4165, qt-sdk 8d0e5d9)
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Picks up logos-co/logos-cpp-sdk#68 — marshals provider event emission onto the
remoting source thread. Part of propagating the fix to the host runtime.
Khushboo Mehta