Signals and Slots over interface

All-

I've got a collection of plugin classes that all implement a proper interface (ie, it the class does not inheirit from QObject) that I'd like to get signals working over. To illustrate (hoping this works and clarifies the issue):

Code:

---

CommonClass    InterfaceClass
| (inherits)     |
|                | (implements)
|+Plugin1+-------|
|+Plugin2+-------|
|+Plugin3+-------|

---

** CommonClass (compiled into library) extends QObject, and has declarations for signals and slots
** Each Plugin class (compiled into library) extends CommonClass in a "is-a" pattern
** InterfaceClass is an interface with *no* implementation and is not a QObject subclass
** MainApplication loads PluginN classes via QPluginLoader by qobject_cast-ing to InterfaceClass

Since InterfaceClass doesn't extend QObject, I can't put signal/slot declarations there; they all extend CommonClass, but it'd be a real pain to qobject_cast the plugins to CommonClass to connect the signals.

I've looked at how the QObject::connect works and see that it eventually uses the QMetaObejcts from the caller and receiver classes. I can use QMetaObject->superClass() to get the classname of a particular plugin (CommonClass, in this example), but don't seem to be able to get a handle on the signal emitted from CommonClass (and, seemingly therefore each plugin).

Thoughts or ideas on how to get this working?

Quote:

---

Originally Posted by SnarlCat

** MainApplication loads PluginN classes via QPluginLoader by qobject_cast-ing to InterfaceClass

Since InterfaceClass doesn't extend QObject, I can't put signal/slot declarations there; they all extend CommonClass, but it'd be a real pain to qobject_cast the plugins to CommonClass to connect the signals.

---

Did it came to you that maybe you could just use the QObject* returned by QPluginLoader?
Connecting signals/slots does not require that you know anything about the nature of the objects involved. As long as they are QObjects the code will compile and as long as they provide the signals you want (wherever it might be in the object hierarchy) the connection will work as expected.

Yes, I tried that.. the QObject::connect(...) failed because it couldn't find the signal in the plugin class as it's declared in CommonClass...

Quote:

---

Originally Posted by SnarlCat

Yes, I tried that.. the QObject::connect(...) failed because it couldn't find the signal in the plugin class as it's declared in CommonClass...

---

Sorry but that doesn't make any sense... When you connect signals/slots the meta object system is queryed in a way that exposes ALL the signals/slots of the object, wherever they may be declared in the inheritance hierarchy.
The only possible issues I can think of are :

• you screwed up signal/slot declaration at some point
• you are actually having DLL-related issues

At this point showing us some code (preferably a small compilable sample reproducing the issue) would help.