> -----Original Message----- > From: interest-bounces+kai.koehne=digia....@qt-project.org > [mailto:interest-bounces+kai.koehne=digia....@qt-project.org] On Behalf > Of Graham Labdon > Sent: Tuesday, May 27, 2014 9:41 AM > To: Interest@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 _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
