[Qt-interest] QObject based plugins

[Andre Somers]

Hi,

Andreas Pakulat wrote:
> On 19.08.09 10:55:18, Andre Somers wrote:
>   
>> In my application, I am using a lot of plugins. I am currently using 
>> QPluginLoader and the Q_DECLARE_INTERFACE macro to define the interface. 
>> However, I find the system a bit limited. While my plugins turn up as 
>> QObjects and I can give them signals and slots, I can only do that in 
>> the specific implementation. The interface itself is not a QObject.
>>
>> I would really like to be able to create an interface complete with all 
>> the wonderfull features Qt offers: signals, slots, introspection, etc. I 
>> know I can cast the loaded plugins to QObject and connect to signals and 
>> slots I know are (should be) there, but that is not a very nice way of 
>> working. That means that the interface I define, is not really the 
>> complete interface.
>>
>> Is there some way to make the plugins right from the interface 
>> definition real QObjects?
>>     
>
> You could do that with one interface, but probably not all because....
>
>   
>> And does that also work if a plugin object implements more than one
>> QObject-like interface?
>>     
>
> This won't work. You cannot inherit multiply from QObject.
>
> Now I don't know your plugin-loading-mechanism, but usually such mechanisms
> have a base class in a shared library that all plugins subclass from and
> then add the individual interfaces. Then the plugin-loading-mechanism just
> returns this base class and you can then cast to the interface you want.
>
> Also QPluginLoader already gives you a QObject when using a plugin via the
> instance() method.
>
>   
Hi,

Thanks for your answer.
I *know* the QPluginLoader already gives you a QObject using the 
instance() method. This is what I tried to describe in my question and 
this is what I am doing now. It is this very mechanism that is bothering 
me, as I have not been able to make the base interface class a QObject 
derived class. It is the multiple-QObject-inheritance that is biting me 
there, I think.

I find the way QPluginLoader magically creates QObject's out of 
something that is not a QObject to be a bit disturbing. It seems to me 
that the only reason to do so, is that it can now use qobject_cast<> to 
try to see if an object implements an interface. While that is a nice 
feature, it is overkill to magically make the plugin instance a QObject 
only for that, thereby blocking the possibility of defining the 
interface as a QObject in the first place! If I want something to be 
QObject-derived, I'll say so myself...

I understand that I can not directly use the multiple QObject-derived 
interfaces approach. I would already be glad if a single QObject-derived 
interface would work. Still, I think it should be possible to achieve 
something like it with some MOC (-like) magic. It might not be easy, but 
it would be cool...

Let me rephrase my question then:
I have a series of interfaces that plugins can implement. There is one 
main, basic interface, and a series of smaller, secundairy interfaces 
that the plugins can *additionally* implement. These interfaces are 
defined in a header that is included from the main codebase by the 
plugins. I am using QPluginLoader::instance() and the 
Q_DECLARE_INTERFACE and Q_INTERFACES macro's to define and load the 
plugins.
Is there some way to make my primairy interface QObject derived, so I 
can define the needed signals and slots in the interface?

André