QObject inherittance problems

[KShots]

I'm just having trouble coming to grips with this issue. At the moment, I'm trying to figure out how to implement a widget base class that can be sub-classed by either a QWidget-based class or a QGLWidget-based class. I can't figure out how to implement such a structure . Here's the problem:

.
                  +-----------------+
                  | Abstract Base   |
                  |     Class       |
                  +-----------------+
                        /    \
                       /      \
                      /        \
                     /          \
   +-----------------+          +------------------+
   | QWidget-based   |          | QGLWidget-based  |
   |      class      |          |      class       |
   +-----------------+          +------------------+

.
                  +-----------------+
                  | Abstract Base   |
                  |     Class       |
                  +-----------------+
                        /    \
                       /      \
                      /        \
                     /          \
   +-----------------+          +------------------+
   | QWidget-based   |          | QGLWidget-based  |
   |      class      |          |      class       |
   +-----------------+          +------------------+

To copy to clipboard, switch view to plain text mode 

The abstract base class would include signals and slots that its sub-classes would implement. This creates a problem. If I were to say that the abstract base class inheritted QWidget, I can make the QWidget subclass work, but not the QGLWidget. If I were to say that the abstract base class inheritted QGLWidget, I can make the QGLWidget subclass work, but not the QWidget subclass. If I were to simply make the abstract base class inherit QObject, neither would work. Any idea how to resolve such a thing?

I can't get rid of all reference to a QObject ancestor because I require the virtual signals and slots inherittance.

[wysota]

In general you can't do it this way. In this situation the base class can't inherit QObject. Maybe instead of inheritance you should use some other association? For example a has-a relationship? Could you explain what you're trying to do?

[KShots]

basically, what I'm trying to do is define an interface that a bunch of plugins should follow. Each plugin should implement a series of slots. If they fail to do so, they need to produce a compile-time error. Theoretically, I could do this by not inheritting the base class at all and implementing the slots in the individual plugins, but if a plugin fails to implement a slot, it will still compile and run with weird results.

Here's the structure of what I've got:

.
        +------------------+         +--------------------------------+
        | Plugin Interface |         | Abstract base class with slots |
        +------------------+         +--------------------------------+
                 |                            |
        +------------------+         +------------------------------+
        | Plugins (a,b...) |---------| QWidget/QGLWidget sub-class  |
        +------------------+         +------------------------------+

.
        +------------------+         +--------------------------------+
        | Plugin Interface |         | Abstract base class with slots |
        +------------------+         +--------------------------------+
                 |                            |
        +------------------+         +------------------------------+
        | Plugins (a,b...) |---------| QWidget/QGLWidget sub-class  |
        +------------------+         +------------------------------+

To copy to clipboard, switch view to plain text mode 

The section on the right is a simplified version of my previous diagram. My plugin has a "has a" relationship with the QWidget / QGLWidget class, which it would return on request (effectively bypassing the plugin itself requiring QWidget, and theoretically allowing the QWidget to have abstract slots defined that all plugins should follow).

[KShots]

Ok, I think I can get away with this if I seperate things one more step further:

.
        +-----------+  +-------------------+ +------------------+
        | Plugin    |  | Abstract class    | | Abstract base    |
        | Interface |  | knows about slots | | class with slots |
        +-----------+  +-------------------+ +------------------+
             |                  |                     |
        +---------+    +-------------------+ +----------------+
        | Plugins |----| QWidget/QGLWidget |-| plugin slots   |
        | (a,b...)|    |     sub-class     | | implementation |
        +---------+    +-------------------+ +----------------+

.
        +-----------+  +-------------------+ +------------------+
        | Plugin    |  | Abstract class    | | Abstract base    |
        | Interface |  | knows about slots | | class with slots |
        +-----------+  +-------------------+ +------------------+
             |                  |                     |
        +---------+    +-------------------+ +----------------+
        | Plugins |----| QWidget/QGLWidget |-| plugin slots   |
        | (a,b...)|    |     sub-class     | | implementation |
        +---------+    +-------------------+ +----------------+

To copy to clipboard, switch view to plain text mode 

This way, my plugin can pass a QWidget, which would have an implementation class of slots. I think the nature of my slots would allow such a relationship. It may get tricky, depending on the plugin, as far as gaining access to the QWidget itself (perhaps a pointer to the QWidget sub-class in the slots implementation?), but I think it's doable. The "abstract class that knows about slots" does not inherit QObject or similar, but it knows about the abstract base class with slots (and includes it as a pointer variable).

EDIT: This structure compiles. I think I have a solution. Thanks for the idea .

[Eldritch]

I'm going to skip drawing the ASCII art here. :P

But, I've done something similar using a template as my base class. It may hamper usage of signals and slots, though -- haven't tested that.

The 'leaf' classes inherit the template, which has two arguments: the QWidget-based class and the plugin interface:

template<class QW, class PI>
MyMixer
{
};

then

class MyWidgetWithCoolStuff : public MyMixer<QWidget, PlugIn>
{
Q_OBJECT
};

...

class MyOtherWidgetWithCoolStuff : public MyMixer<QGLWidget, PlugIn>
{
Q_OBJECT
};

As I said... I haven't had the need to use signals / slots with this, so I wouldn't be surprised of moc has trouble with it. In my case, I have several separate "mixin" interfaces that one can pair with a QWidget-based window, and the template implements all the common code.

Fun! Fun! FUN!!!