mirror of
https://github.com/logos-co/logos-module-viewer.git
synced 2026-08-27 12:01:14 +00:00
Dario Gabriel LipicarandClaude Opus 5
7111e028b9
Supersedes the necessary-but-not-sufficient nlohmann change: the bump works now.
Three unrelated things blocked it, and only the third came from the
shared-runtime migration. Worth separating, because "bump the pin" reads like
one task and is three.
1. nlohmann_json in buildInputs. liblogos re-exports the Qt host runtime
headers, two of which include <nlohmann/json.hpp>. It has to be declared
HERE: logosLiblogos arrives as a bare attribute and is interpolated as
${logosLiblogos}/include, so there is no dependency edge for
logos-liblogos#184's propagation to travel along.
2. SOURCE-LEVEL API DRIFT, pre-existing and unrelated to the migration. This
repo was written against an older LogosAPIClient:
- requestObject returns LogosObject*, not QObject*. LogosObject is a plain
class, not a QObject, so m_eventSubscriptions is retyped. It is only ever
used for contains() / assignment / clear() and never dereferenced, so
that is a type change and not a behaviour change.
- onEvent takes THREE arguments; this called it with four, passing nullptr
for a placeholder that no longer exists.
- The C API renamed "plugin" to "module": set_plugins_dir ->
add_modules_dir (note ADD, not SET -- it appends a search directory),
process_plugin -> process_module, load_plugin -> load_module, which also
gained a with_dependencies argument. Passing true: a viewer loading a
module to inspect it needs the module's dependencies up too.
3. LINKING THE SHARED RUNTIME, which is the migration's actual consumer
requirement. liblogos_core used to absorb liblogos_protocol.a and
liblogos_qt_host.a whole and re-export them, so linking it alone resolved
LogosAPIClient and friends. Since logos-liblogos#182 it IMPORTS them, and a
consumer linking only liblogos_core fails at link time:
Undefined symbols: LogosAPIClient::onEvent(LogosObject*, QString const&, ...)
So app/CMakeLists.txt finds and links liblogos_protocol and liblogos_qt_host,
and FAILS LOUDLY if they are absent rather than falling back to a link that
cannot work.
VERIFIED, aarch64-darwin:
nix build .#default OK
lib/ staged liblogos_core, liblogos_protocol,
liblogos_qt_host, libpackage_manager_lib
dlopen liblogos_core.dylib OK
running the viewer rc=124 (timeout kill, i.e. it ran) with no
dyld diagnostic
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
logos-module-viewer
A Qt UI application for viewing Logos modules.
Screenshot
Usage
./logos-module-viewer --module ./path/to/module.dylib
Note: for now only works with modules that don't need to call another module.
This will load the specified Qt plugin module and display its methods in the UI.
How to Build
Using Nix (Recommended)
Build the Application
# Build the app (default)
nix build
# Or explicitly
nix build '.#app'
The result will include:
/bin/logos-module-viewer- The Module Viewer application
Development Shell
# Enter development shell with all dependencies
nix develop
Note: In zsh, you need to quote the target (e.g., '.#app') to prevent glob expansion.
If you don't have flakes enabled globally, add experimental flags:
nix build --extra-experimental-features 'nix-command flakes'
The compiled artifacts can be found at result/
Running the Application
After building with nix build, you can run it:
# Run the application
./result/bin/logos-module-viewer
Nix Organization
The nix build system is organized into modular files in the /nix directory:
nix/default.nix- Common configuration (dependencies, flags, metadata)nix/app.nix- Application compilation
Output Structure
When built with Nix:
result/
└── bin/
└── logos-module-viewer # Qt application
Requirements
Build Tools
- CMake (3.16 or later)
- Ninja build system
- pkg-config
Dependencies
- Qt6 (qtbase)
- Qt6 Widgets (included in qtbase)