[Interest] Design of 'pluginable' application

[Koehne Kai]

> -----Original Message-----
> From: interest-bounces+kai.koehne=digia.com at qt-project.org
> [mailto:interest-bounces+kai.koehne=digia.com at qt-project.org] On Behalf
> Of Graham Labdon
> Sent: Tuesday, May 27, 2014 9:41 AM
> To: Interest at qt-project.org
> Subject: [Interest] Design of 'pluginable' application
> 
> Hi
> I am designing an application built around plugins.
> I know how to create plugins and read them in at run time, but now I need a
> way of invoking the signal/slot mechanism between them.
> For example, in a simple scenario I have plugin1 that has a slot for processing
> a signal the plugin2 emits.
> Plugin1 knows (nor should it) nothing about plugin2.
> 
> One approach I thought of (not implemented yet) is to create a map of
> signals and slots that a plugin defines using the QMeta System and then
> processing these maps to create the connections. There would have to be
> some kind of naming convention(similar to the uic connectByName).
> 
> Is this a good plan?

Do you need the flexibility that any plugin potentially talk to any other plugin, configurable at runtime? If not, the approach sounds a bit over-engineered for my taste ;) The alternative is to define some (abstract) API in a common plugin/your main executable, where one plugin implements the API, the other one uses it ...

> How is this generally implemented?

You might have a look at Qt Creator sources. It's built around plugins, and has quite some infrastructure for it (including  full Plugin Manager with a nifty 'Object Pool').

http://doc.qt.digia.com/qtcreator-extending/creating-plugins.html
http://doc.qt.digia.com/qtcreator-extending/extensionsystem-pluginmanager.html

Regards

Kai