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)?
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With