Files
logos-plugin-qt/cpp/logos_provider_object.h
T
Dario Gabriel LipicarandClaude Opus 5 eac67af9e3 feat: the Qt host runtime and the cdylib-glue generator
This repo was the Qt plugin BUILD backend — pure Nix functions plus a CMake
module, with no C++ target at all. But the two things a Qt host actually needs
at runtime lived in logos-qt-sdk, where they are neither a language wrapper over
the protocol C API nor codegen:

  LogosAPI / LogosAPIProvider   owns a LogosTransportHost per transport,
                                constructs ModuleProxy / ModuleHandshakeProxy,
                                publishes the handshake surface, seeds trust
                                anchors, injects the token validator
  LogosProviderBase             the base every generated provider derives
  PluginInterface               the Qt plugin loading contract
  the cdylib->Qt glue generator the emitter that wraps a language-neutral
                                cdylib in a Qt plugin

They move here, so "swap the plugin technology" is a one-repo change.

ADDITIVE: the sources are COPIED and logos-qt-sdk is untouched. Removing them
there now would turn nine downstream masters red at once; that comes later,
after consumers are repointed.

qt_provider_object (and logos_qt_arg_decode, which its QMetaObject dispatch
needs) is carried deliberately even though it is legacy: logos_api_provider
falls back to wrapping a plain QObject in it, and the modules that rely on that
have not been migrated yet. It goes once they are.

The generator links Qt Core and logos-lidl only — never logos-cpp-sdk. It needed
exactly one helper from that SDK's shared frontend, lidlToPascalCase (~12
lines), which is inlined instead, the same way logos-view-module does it. It
also REFUSES `--backend <anything but cdylib>` rather than ignoring the flag:
callers are migrating from a tool where --backend was required and dispatched
on, so silently treating `--backend qt` as cdylib would emit confidently wrong
artifacts with a zero exit.

`rawLib`, `lib` and `cmake-module` deliberately do not reference the new
derivations, so a consumer that only wants the Nix build functions never
realises a Qt/protocol build. Proven, not assumed: with both new inputs
overridden to a bogus flake, cmake-module and rawLib still evaluate while
logos-qt-host fails — so the override bites and the cheap outputs really never
touch it.

Behaviour preservation is the whole claim of a relocation, so it is measured:
the emitted glue is BYTE-IDENTICAL to logos-qt-generator --backend cdylib over
every one of the 20 .lidl contracts in the workspace, in both single and
concurrency:multi mode (40 pairs, exit codes included), and single vs multi do
differ from each other, so both code paths were really exercised. The built
liblogos_qt_host.a is byte-identical to liblogos_qt_sdk.a, exporting the same
390 symbols.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-16 09:07:04 -03:00

78 lines
3.2 KiB
C++

#ifndef LOGOS_PROVIDER_OBJECT_H
#define LOGOS_PROVIDER_OBJECT_H
#include <QString>
#include <QVariant>
#include <QVariantList>
#include <QJsonArray>
#include <nlohmann/json.hpp>
#include <functional>
#include <string>
#include <vector>
#include "logos_json_convert.h"
// The abstract LogosProviderObject interface (the provider-side counterpart
// of LogosObject, wrapped by ModuleProxy) moved to logos-protocol with the
// transport layer — see logos_provider_interface.h. This header keeps its
// historical name and continues to carry the developer-facing pieces:
// LogosProviderBase (which hands a LogosAPI* to module code, hence it lives
// here above the protocol layer), LogosProviderPlugin, and the
// LOGOS_PROVIDER / LOGOS_METHOD macros.
#include "logos_provider_interface.h"
class LogosAPI;
// ---------------------------------------------------------------------------
// LogosProviderBase — convenience base class for new-API modules
//
// Handles framework plumbing so the developer only writes business logic.
// callMethod() and getMethods() are provided by generated code produced
// by logos-cpp-generator --provider-header (analogous to Qt MOC).
// ---------------------------------------------------------------------------
class LogosProviderBase : public LogosProviderObject {
public:
// These two are implemented by generated code (logos_provider_dispatch.cpp):
// QVariant callMethod(const QString& methodName, const QVariantList& args) override;
// QJsonArray getMethods() override;
void setEventListener(EventCallback callback) override { m_eventCallback = callback; }
bool informModuleToken(const QString& moduleName, const QString& token) override;
void init(void* apiInstance) override;
protected:
void emitEvent(const QString& eventName, const QVariantList& data);
virtual void onInit(LogosAPI* api) {}
LogosAPI* logosAPI() const { return m_logosAPI; }
private:
EventCallback m_eventCallback;
LogosAPI* m_logosAPI = nullptr;
};
// LogosProviderPlugin (the plugin-detection interface) now lives in
// logos-protocol's logos_provider_interface.h, included above — it stays
// visible to existing includers of this header.
// ---------------------------------------------------------------------------
// Macros — the developer-facing API
// ---------------------------------------------------------------------------
// LOGOS_PROVIDER: declares providerName/providerVersion and a private typedef.
// Place at the top of the class body (like Q_OBJECT).
#define LOGOS_PROVIDER(ClassName, Name, Version) \
public: \
QString providerName() const override { return Name; } \
QString providerVersion() const override { return Version; } \
QVariant callMethod(const QString& methodName, const QVariantList& args) override; \
QJsonArray getMethods() override; \
private: \
using _LogosProviderThisType = ClassName;
// LOGOS_METHOD: marks a method as callable by the framework.
// Expands to nothing — scanned by logos-cpp-generator to produce
// callMethod() dispatch and getMethods() metadata (like Q_INVOKABLE + MOC).
#define LOGOS_METHOD
#endif // LOGOS_PROVIDER_OBJECT_H