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>
