Qt Application Plugins with the same interface
-
Hello everyone,
I am following the echoplugin example to understand how to build a structure of plugins for my application.
In my case I think my set of plugins would share the same interface. My question is how to set an interface class that would be used by multiple plugins?
I currently have this interface which is the similar to the one in the example.
#ifndef WIDGETS_INTERFACE_H #define WIDGETS_INTERFACE_H #include <QObject> //! [0] class Widgets_interface { public: virtual ~Widgets_interface() = default; virtual QWidget* open(QWidget* parent) = 0; virtual void close() = 0; }; QT_BEGIN_NAMESPACE #define Widgets_interface_iid "Widgets_interface" Q_DECLARE_INTERFACE(Widgets_interface, Widgets_interface_iid) QT_END_NAMESPACE //! [0] #endifIf i load this interface in the main application I obviously have no way to differentiate which plugin am I loading.
bool EchoWindow::loadWidget02Plugin() { QDir pluginsDir(QCoreApplication::applicationDirPath()); #if defined(Q_OS_WIN) if (pluginsDir.dirName().toLower() == "debug" || pluginsDir.dirName().toLower() == "release") pluginsDir.cdUp(); #elif defined(Q_OS_MAC) if (pluginsDir.dirName() == "MacOS") { pluginsDir.cdUp(); pluginsDir.cdUp(); pluginsDir.cdUp(); } #endif pluginsDir.cd("plugins"); const QStringList entries = pluginsDir.entryList(QDir::Files); for (const QString& fileName : entries) { QPluginLoader pluginLoader(pluginsDir.absoluteFilePath(fileName)); QObject* plugin = pluginLoader.instance(); if (plugin) { widget02_interface = qobject_cast<Widgets_interface*>(plugin); if (widget02_interface) return true; pluginLoader.unload(); } } return false; }Does this mean I need to have a different header/interface file for each plugin even if they share the same functionality?
Sorry for my very basic question. I'm still learning.
Thank you,
w@wasawi2 said in Qt Application Plugins with the same interface:
if they share the same functionality?
Why would two plugins do the same for different types? What's the use-case?
-
@wasawi2 said in Qt Application Plugins with the same interface:
if they share the same functionality?
Why would two plugins do the same for different types? What's the use-case?
@Christian-Ehrlicher thank you for asking.
Actually Im not even sure using plugins is the best solution for my use case.
My idea it was to have a launcher application that loads a set of plugins (10 to 20) and each of them loads its own UI and has different functionalities. The launcher application only needs to call open or close to each plugin, so the interface is the same for all of them. This way I can have some advantages in maintenance, I can work in one plugin knowing that I don't have to recompile and ship the entire application but only one of its plugins. This may introduce some complexity when it comes to keeping track of each plugin version, but that is not a problem for now..
So for what I understand the interface should be the same for all of them. Should i have a different class name and header file for each plugin? even if the open and close will be the same for all of them?
Thank you,
w -
Hi,
The interface stays the same. What can change is what you use for the implementation. In the example you show, there's a different handling between macOS and Windows. In some circonstances, you may have one implementation file per platform but it's nothing unusual nor overly complex to manage.
@SGaist said in Qt Application Plugins with the same interface:
The interface stays the same. What can change is what you use for the implementation.
Ok, so the open and close functions remain the same but the class name, the #define and the Q_DECLARE_INTERFACE has to be different?
So I need a different header file for each plugin?Sorry for my very basic question.. I'm a bit confused.
Thank you,
w -
Check for example the Qt SQL plugins, that might be simpler to get the structure right.
-
@SGaist thank you! But I can not find any Qt SQL plugins example in the example folder... I'm on Qt 6.5.2.
I had a look at the plugandpaint example but that didn't help much.
-
I still don't see the usecase here. Why one plugin with two different interfaces? The sql plug-ins for sure don't make such hacks - I would be aware of (and fixed it) :)
-
@jsulm said in Qt Application Plugins with the same interface:
@wasawi2 I think @SGaist means to check the implementation of SQL plug-ins (source code) to see how it is done there
Exactly that
-
Why make a plugin system anyway? Do you have an ecosystem with 3rd party developers providing features for your app?
If not then why complicate things? Making a robust plugin system with interfaces, versioning, correct loading unloading and handling transient dependencies to Qt and CRT and any other library and dealing with correct runtime resource management is just a ton of complications. Also your build files get more complicated with more build targets and more build rules.
Ideal code base has nothing in it.
0 lines of code, 0 lines of build rules, 0 bugs, 0 headaches.From the engineering perspective any line of code you add, any build target you add, any library you add can only server to make things worse for you.
-
Why make a plugin system anyway? Do you have an ecosystem with 3rd party developers providing features for your app?
If not then why complicate things? Making a robust plugin system with interfaces, versioning, correct loading unloading and handling transient dependencies to Qt and CRT and any other library and dealing with correct runtime resource management is just a ton of complications. Also your build files get more complicated with more build targets and more build rules.
Ideal code base has nothing in it.
0 lines of code, 0 lines of build rules, 0 bugs, 0 headaches.From the engineering perspective any line of code you add, any build target you add, any library you add can only server to make things worse for you.
