Problem with Qt plugin system

[fullmetalcoder]

if I need to share some concrete methods (which the pkServer instance needs to know too) with all applications derived from pkApplication interface? How can I do that?

it is recommended to avoid that as much as possible. Your plugin system should be designed (mostly) one-way : the application call methods from the plugin and the plugin acts on its own.
For the cases where it is really needed, there are two main ways :

• passing pointers to "controllers" object (recommened method in most cases, more on this below)
• putting all the common code in a shared lib. both the app and the plugins would link against it

A controller object is basically a class that allows the plugin to obtain data or to perform actions in a way that is not "predictable" by the app.

Just create another abstract class exposing methods of interest (which must be pure virtual). Then subclass that class in your app to provide actual implementation of these methods and pass a pointer to an object of your controller class to the plugins. e.g :

class pkApplicationController
{
public:
    virtual ~pkApplicationController() {}
 
    virtual QString statusMessage() const = 0;
    virtual void setStatusMessage(const QString& s) = 0;
};

class pkApplicationController
{
public:
    virtual ~pkApplicationController() {}
    
    virtual QString statusMessage() const = 0;
    virtual void setStatusMessage(const QString& s) = 0;
};

To copy to clipboard, switch view to plain text mode 

class pkConcreteAppController : public pkApplicationController
{
public:
    QString statusMessage() const { return m_status; }
    void setStatusMessage(const QString& s) { m_status = s; }
};

class pkConcreteAppController : public pkApplicationController
{
public:
    QString statusMessage() const { return m_status; }
    void setStatusMessage(const QString& s) { m_status = s; }
};

To copy to clipboard, switch view to plain text mode 

// somewhere in your app : (pointerToController is a pkConcreteAppController*)
plugin->someMethod(pointerToController);

// somewhere in your app : (pointerToController is a pkConcreteAppController*)
plugin->someMethod(pointerToController);

To copy to clipboard, switch view to plain text mode 

// in a plugin
void SomePlugin::someMethod(pkApplicationController *c)
{
    if ( !happy )
        c->setStatusMessage("Always look at the bright side of life.");
}

// in a plugin
void SomePlugin::someMethod(pkApplicationController *c)
{
    if ( !happy )
        c->setStatusMessage("Always look at the bright side of life.");
}

To copy to clipboard, switch view to plain text mode 

I hope this helps.

[zuck]

Yes, this is a solution.

What about using QLibrary instead of QPluginLoader? With QLibrary can I have an abstract base class (no pure virtual methods only) as "parent" for all derived applications?

[fullmetalcoder]

using QLibrary instead of QPluginLoader offers a single avantage : more control. QPluginLoader actually uses a QLibrary under the hood so the same restrictions apply. Besides, using QLibrary implies recreating what QPluginLoader provides (you cannot create objects directly from shared libs, you have to export a "creator" functions which must have a name known to the plugin loading code, must be mangled properly, ...)

Just to clarify about the requirements on a "base class" for plugins (provided you don't use a "common shared lib" approach) :

• such a class does not need to be pure virtual (aka abstract) stricto sensu (it can inherit non-abstract classes for instance)
• it must however be pure virtual in a "practical sense", which basically means that the only methods it brings (on its own, see previous remark) must be pure virtual and it cannot have member variables of its own

An important consequence is that such a class can inherit QObject for instance but then the Q_OBJECT macro must be omitted as it adds members/methods used by the meta object system.

[zuck]

So I can write the inverse of original situation:

class pkApplicationBase : public QObject
{
   // The id logic here (without Q_OBJECT macro).
};
 
class pkApplication : public pkApplicationBase
{
    // abstract interface here.
};

class pkApplicationBase : public QObject
{
   // The id logic here (without Q_OBJECT macro).
};

class pkApplication : public pkApplicationBase
{
    // abstract interface here.
};

To copy to clipboard, switch view to plain text mode 

Is it correct?

[fullmetalcoder]

No. You can afford to use "semi-abstract" classes as base class for plugins because both your app and the plugin links to Qt libs dynamically (or any other shared lib providing classes that you could be tempted to use as ancestors of your plugin base class).

Any class that brings at least one method/member variable of its very own (i.e not through inheritance of a class defined in a common shared lib) is definitely unreachable from plugins (unless, again, you move it to a common shared lib).

Please not that the shared is equally important as the common. You may manage to get it working in some cases when compiling a common lib statically but it is extremely likely to fail miserably or a reason or another in a vast majority of cases.

In any case you're safer using only (totally) pure virtual classes in your plugin system and, if needed, a bit of meta-object magic here and there.

[zuck]

So the correct procedure is:

1) Put pkApplication and pkApplicationBase in a shared lib.
2) Link ExampleApp and pkServer modules to the shared lib.

...Right?