[Interest] Design of 'pluginable' application

[Christoph Kurz]

Usually things like that are done using the "EventBus"-Pattern. I don't know the
Qt-Plugin-System, so I'm not sure if it is applicable for you...

It usually works like this:
- You have an "EventBus"-object in your application (not in the plugins!) which
is a singleton, so only one instance is created and it is accessible from
everywhere.
- All the plugins send their events (or signals) to the EventBus (as they don't
know the other plugins). This means that the EventBus must either know about all
possible signals or a generic signal is sent with the meta-information in the
parameters (e.g. genericSignal(SignalType type, QVariant value))
- All plugins that want to receive a specific signal register themselves at the
EventBus for this signal (e.g. EventBus::register(QObject* receiver, SignalType
type)). This way the receiver gets all the signals of type "type".
- The EventBus implements the logic. It keeps a list of receivers for every
SignalType, and if a signal comes from a plugin it send signals to each receiver
in the corresponding list.

I hope the principle is understandable from what i just wrote... if not, you can
just google "EventBus" and you will find something, i guess.

Be aware that it doubles the amount of signals sent between plugins, though that
is rarely a performance problem.

Regards,
Christoph


> -----Original Message-----

> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20140527/2d1e2229/attachment.html>