The `--backend ui` emitter existed twice: live in logos-qt-sdk's
qt-generator, and as an uncalled successor here. They were byte-identical
until logos-qt-sdk#38 gave the live one the module teardown hook, and this
copy has been ~45 lines behind ever since.
That drift is dangerous in a specific way. ui-host reaches aboutToUnload()
BY NAME through the meta-object; a plugin class that does not declare it has
no such meta-method, invokeMethod returns false, and the host moves on —
INDISTINGUISHABLE from a plugin answering "Synchronous, nothing to wait
for". Had the migration completed with this copy, every view would have
silently and permanently lost its chance to finish, and nothing would have
failed: not a build, not a load, not a call.
This repo is the right home. The emitter needs nothing from logos-qt-sdk —
`--backend ui` is the one qt-generator backend that never reads LIDL, and
its only qt-sdk symbol was lidlToPascalCase, which this copy already
inlines. The LogosView*.in templates the generated glue compiles against
already live here. And the backend owning its glue is the same rule that
puts the cdylib glue generator in logos-plugin-qt.
logos_ui_plugin_context.h HAD TO COME TOO, which the plan did not
anticipate. It was duplicated as well, and stale by the same changeset. The
emitter and that header are a matched pair — the emitter writes a call, the
header declares what it calls — and they stayed consistent only because one
pin versioned both. Moving the emitter alone fails concretely:
`no member named 'maybeUiPluginAboutToUnload' in namespace '_logos_codegen_'`.
The emitter is taken VERBATIM: the .cpp differs from the live copy only in
three generator-name banners, and the .h and the context header are
byte-identical to it. Every difference in the successor was it being behind
or vaguer — two were outright regressions (the .h named LogosModuleContext,
the exact confusion the live comment warns against, and the .cpp described
emitted files by names neither main uses).
main.cpp accepts `--backend ui` and refuses anything else, converging with
the in-flight qml-dep branch rather than colliding with it.
TESTS CARRIED ACROSS, because the old home's blind spot is the whole story:
`--backend ui` had NO test at all, which is how it became the one generated
plugin class without the hook. qt-sdk's five text assertions come over, plus
a new behavioural check: tests/ui-plugin-metaobject compiles the emitted
plugin against the REAL context header and REAL templates, loads it with
QPluginLoader, and dumps the meta-object —
[4] SIGNAL unloadFinished() [5] METHOD initLogos [6] METHOD aboutToUnload -> int
Negative control: origin/master's stale emitter compiles and loads fine and
the check still fails with both named diagnostics. The silent gap, made loud.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A view module is a distinct authoring flavour, not a variation on a core
module: it publishes a .rep rather than a .lidl, and is driven by a QML view in
a ui-host process. Its two halves were split across two repos that own other
things — the plugin-glue generator sat in logos-qt-sdk's qt-generator, and the
replica-factory CMake plus its four templates sat in logos-plugin-qt — so
changing how views are built meant touching the SDK and the Qt plugin backend.
Collected here:
- view-generator/ logos-view-generator, emitting <name>_ui_interface.h and
<name>_ui_glue.{h,cpp} around the user's .rep + *Backend.
Carried over verbatim from logos-qt-sdk's lidl_gen_ui, with
a main() of its own. It never reads LIDL — a view's contract
IS its .rep — so it links Qt Core and nothing else, and
lidlToPascalCase is inlined rather than dragging in a
generator frontend it has no other use for.
- cmake/ LogosViewModule.cmake wrapping logos_replica_factory(), with
the four .in templates it configures. They must stay
siblings: the function resolves them through
CMAKE_CURRENT_FUNCTION_LIST_DIR.
- cpp/ LogosUiPluginContext, the narrow context a *Backend derives.
That makes this repo a leaf — logos-nix for a pinned Qt, nothing else — so it
can be re-pinned independently of the SDK stack.
Verified behaviour-preserving rather than assumed: run against a real in-tree
view module (logos-chat-ui's ChatBackend.rep + metadata.json), the relocated
generator's three files are BYTE-IDENTICAL to logos-qt-generator --backend ui.
Two checks: one drives the generator over a real .rep and asserts the scraped
rep class, the PascalCase plugin stem and the carried version; the other
asserts a .rep declaring no class fails rather than emitting half a plugin.
The originals are left in place for now — additive first, removal second, so
no downstream repo goes red on this commit alone.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
