Question

I’m making a task-based program that needs to have plugins. Tasks need to have properties which can be easily edited, I think this can be done with Qt’s Meta-Object Compiler reflection capabilities (I could be wrong, but I should be able to stick this in a QtPropertyBrowser?)

So here’s the base:

class Task : public QObject
{
Q_OBJECT
public:
    explicit Task(QObject *parent = 0) : QObject(parent){}

    virtual void run() = 0;

signals:
    void taskFinished(bool success = true);
}

Then a plugin might have this task:

class PrinterTask : public Task
{
Q_OBJECT
public:
    explicit PrinterTask(QObject *parent = 0) : Task(parent) {}

    void run()
    {
        Printer::getInstance()->Print(this->getData());  // fictional
        emit taskFinished(true); 
    }

    inline const QString &getData() const;
    inline void setData(QString data);

Q_PROPERTY(QString data READ getData WRITE setData) // for reflection
}

In a nutshell, here’s what I want to do:

// load plugin
// find all the Tasks interface implementations in it
// have user able to choose a Task and edit its specific Q_PROPERTY's
// run the TASK

It’s important that one .dll has multiple tasks, because I want them to be associated by their module. For instance, “FileTasks.dll” could have tasks for deleting files, making files, etc.

The only problem with Qt’s plugin setup is I want to store X amount of Tasks in one .dll module. As far as I can tell, you can only load one interface per plugin (I could be wrong?). If so, the only possible way to do accomplish what I want is to create a FactoryInterface with string based keys which return the objects (as in Qt’s Plug-And-Paint example), which is a terrible boilerplate that I would like to avoid.

Anyone know a cleaner C++ plugin architecture than Qt’s to do what I want?

Also, am I safely assuming Qt’s reflection capabilities will do what I want (i.e. able to edit an unknown dynamically loaded tasks’ properties with the QtPropertyBrowser before dispatching)?

Answer 1

Sounds like you’ve been giving this a thorough thought, which is great and needed. I cannot comment on the Qt specifics, but be sure to not miss out on these pieces of plugin advice, particularly versioning: Plugin Architecture

EDIT: The original link above is borked (was added 8 years ago…). The Wayback Machine has a copy though