может, доступны - хотя де юре интерфейс должен быть чисто абстрактным (если это требование не отменили в последних версиях, конечно), де факто вы можете без проблем наследоваться от QObject. но если вы борец за расовую чистоту, ваш интерфейс может возвращать указатель на наследника QObject.

Если не нравится использование этого метода (мне не нравится):

C++ (Qt)
virtual QObject* pluginObject() { return this; }
 

можно в основной программе делать примерно так:

C++ (Qt)
QPluginLoader loader("plugin");
connect(loader.instance(), SIGNAL(pluginSignal()), SLOT(appSlot()));
 

Пробую объявить интерфейс так:

C++ (Qt)
#ifndef INTERFACES_H
#define INTERFACES_H
#include <QObject>
 
class QString;
class CameraInterface : public QObject
{
    Q_OBJECT
public:
    virtual ~CameraInterface() {}
    virtual void powerOn();
    ...
    virtual void extendedCommand(QString command);
 
signals:
    void powerStateCahnged(bool state);
    void backlightStateChanged(bool state);
};
 
Q_DECLARE_INTERFACE(CameraInterface, "ru.myCompany.myApp.cameraInterface/1.0")
 
#endif // INTERFACES_H
 

При попытке сборки валятся ошибки вида:
debug/moc_interfaces.o:moc_interfaces.cpp:(.rdata$_ZTV15CameraInterface[vtable for CameraInterface]+0x38): undefined reference to `CameraInterface::powerOn()'
количеством равным кол-ву виртуальных методов. Насколько я понимаю компилятор пытается найти реализацию вирутальных функций, но зачем он это делает мне не понятно.

Читал вот эту тему http://www.prog.org.ru/topic_8357_0.html никак не могу взять в толк для чего Dendy и Константин советуют в интерфейсе только передавать указатель на создаваемый класс, а не указывать список доступных методов. Я себе представлял что в интерфейсе надо собирать общие для поддерживающих протокол железок методы, чтобы вызывающему плагин приложению было наплевать на реализацию класса для конкретной железки, а советуют делать наоборот 

да, не все то абстрактно, что виртуально

А я нигде и не утверждал, что MyClass не не должен наследоваться от QObject, как раз наоборот. Я имел ввиду, что метод pluginObject() - лишний, потому, что loader.instance() возвращает ровно то же, что pluginObject().

CameraInterface НЕ ДОЛЖЕН наследоваться от QObject! От QObject надо наследоваться классом, который реализует абстрактные методы из CameraInterface (см. пример от Sancho_s_rancho с классом MyClass).

andrew.k меня опередил, но я добавлю - если CameraInterface не будет наследоваться от QObject то как тогда мое приложение использующее плагины узнает о том какие что плагин будет посылать сигналы. Собственно заморочку с плагинами я затеял именно для того чтобы написать нужное кол-во плагинов реализующих конкретный функционал (SonyCamera, AxisCamera, TandbergCamera и т.п.) без необходимости правок в основной программе. Она не должна знать о том что есть все это многообразие, а работать должна со всеми ими через CameraInterface.

Давайте-ка ещё раз и по-спокойнее. Наследоваться от QObject (а так же от CameraInterface) будут классы SonyCamera, AxisCamera, TandbergCamera и т.д. Для них же, а не для CameraInterface, moc сгенерит код для всех их сигналов и слотов. Основному приложению достаточно знать только методы, имеющиеся в CameraInterface и общие для ВСЕХ его наследников сигналы/слоты. В основном приложении на этапе компиляции совсем не нужны moc реализации всего того, что он нагенерит для плагинов.

Вот даже пример набросал.