I would probably say it does not work with any template, but am not completely sure, I would need to test it. From : http://qt-project.org/wiki/QtPlugins

It says, "One of the caveats to be aware of is that moc is not aware of interface inheritance. For example, if ToolInterface derived from GenericInterface, it should be possible to qt_metacast to GenericInterface. moc is no C++ parser and hence it would not add GenericInterface to the qt_metacast code that it generated above. A workaround is to write Q_INTERFACES(ToolInterface:GenericInterface) in hammer.h. The “:” indicates derives."

http://qt-project.org/wiki/QtPlugins

Yes. I also test this fact. Unfortunately, a template class cannot be exported as plugin with the QT lib.

I have never tried to write Plugins with Qt. So, I don't know much about using Q_INTERFACE. I know, though, that Qt has many problems with template classes. At least a couple of years ago the moc could not handle template classes at all. Having a template class derive (directly or indirectly) from QObject together with the obligatory Q_OBJECT macro did not work. I guess that this has not changed. One thing you might try is using Q_DECLARE_INTERFACE instead of Q_INTERFACE (http://qt-project.org/doc/qt-5/qtplugin.html#Q_DECLARE_INTERFACE). I am not exactly sure if this helps you to get around the problems with template classes.

Probably, I solve this problem. It is possible to create any smart class for each plugin of interest. This smart class does not exploit any template. Thus, it can be exploited by the QT Library. Basically, it creates template classes of interest wrt to the FMP pattern thank to template factories. Clearly, it is necessary to register objects to be allocated. This method works very well. It will be released in new version of my Mangrove TDS Library: http://mangrovetds.sourceforge.net by the end of 2015.