Hi Christophe,
Thanks for sharing PlugFrame — this is a genuinely interesting architecture experiment, and it's great to see it already powering a real-world project like OpLink.
The idea of composing applications at runtime through Qt plugins is something more Qt developers should explore. Qt's QPluginLoader and the Q_DECLARE_INTERFACE / Q_PLUGIN_METADATA mechanism give you a surprisingly solid foundation for this kind of thing, but rolling a clean, reusable plugin host layer around it takes real design work — which is exactly what PlugFrame appears to be doing.
A few things I'm curious about after reading your overview:
Plugin discovery & lifecycle — How does PlugFrame handle plugin dependency ordering at load time? For example, if Plugin B depends on a service registered by Plugin A, does the host resolve that before invoking initialize() on B, or is that left to the plugin author to manage?
Inter-plugin communication — Are plugins communicating through shared interfaces (pure virtual classes registered with the host), or is there a signal/bus-based approach? I've seen both patterns in plugin systems; the interface registry approach tends to be cleaner for typed dependencies, while a message bus scales better for loosely coupled events.
CMake integration — Since you're targeting both Linux desktop and Raspberry Pi (ARM), I'd be interested in how you're structuring the CMake targets. Are individual plugins built as separate MODULE targets and deployed to a known directory, or is there a custom install step that assembles the final layout?
The home/building automation domain is a good fit for this kind of architecture — features like protocol adapters, UI panels, and device drivers map naturally to plugins, and being able to swap or add them without recompiling the host is a real operational advantage on embedded targets like the Pi.
Looking forward to following the project's progress. Will give the PDF overview a read and check out the GitHub repos.
