PlugFrame – Experimenting with a Modular Qt Plugin-Based Architecture
-
Hello everyone,
I would like to share an ongoing personal Qt/C++ project named PlugFrame.
The goal of the project is to experiment with a modular runtime architecture based on Qt plugins in order to build extensible and configurable applications.
This architecture is currently being used in another project called OpLink, dedicated to supervision and control systems in the fields of home and building automation.
The work mainly focuses on:
modular application composition,
runtime plugin integration,
application extensibility,
and cross-platform support using Qt/CMake (currently Linux desktop and Raspberry Pi).The project is still under active development, but I would be very interested in technical feedback or discussions with people interested in modular Qt architectures.
GitHub:
PlugFrame: https://github.com/ELEKDOM/PlugFrame
OpLink: https://github.com/ELEKDOM/OpLinkShort presentation of OpLink (video in French):
https://www.youtube.com/watch?v=x41Cz12qT5kBest regards,
Christophe -
As a follow-up to my previous post, I’m sharing a short technical overview document of PlugFrame for developers interested in the project architecture and design approach.
Technical overview PDF:
https://github.com/ELEKDOM/PlugFrame/blob/master/docs/ELEKDOM_PlugFrame_overview.pdfBest regards,
Christophe -
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.
