Some issues in plugin design...
-
I have implemented application as set of plugins and a core app. Each leading class inside plugin inherits from QObject and PluginInterface. All works fine. But now I decided that I need provide some common signals and virtual slots for each plugin class. But plugin interface class IS NOT a QObject. I don't know what is actual reason for this but probably there is some. I think about to implement some BasePlugin class in the baseplugin.h like this:
@
///////// plugininterface.h
class PluginInterface
{
public:
virtual ~PluginInterface() {}
virtual void startPlugin() = 0;
};
Q_DECLARE_INTERFACE( PluginInterface, "my.PluginInterface/1.0" )///////// baseplugin.h:
#include <QObject>
#include <QtPlugin>
#include "plugininterface.h"class BasePlugin : public QObject, public PluginInterface
{
Q_OBJECT
Q_INTERFACES( PluginInterface )signals:
// all needed signalspublic slots:
// all needed virtual slots, some are pure virtual
}Q_EXPORT_PLUGIN2( PluginInterface, BasePlugin )@
then include baseplugin.h into leading .cpp file of each plugin and inherit each other plugin class from it. But I'm not sure about Qt plugin system and how this will work with Q_EXPORT_PLUGIN2 macro taking BasePlugin class IN ALL future plugins.
@#include "baseplugin.h"
class SomePlugin : public BasePlugin
{
virtual void startPlugin();public slots:
// implementation of virtual slots
}@Please explain me more about Q_EXPORT_PLUGIN2 macro. Will my design work without problems with all possible future plugins implemented like SomePlugin above?
-
Your message is too abstract. Please explain you idea deeply. Please do not forget that plugin can be crated by any other people years later. And they can be created by unknown people around the world. Do not forget that plugin must communicate not to core but to each other plugin trough signals/slots. Core app exactly just only connects plugins between them. This is main design of this app, and it is not a subject to change.
Please stick on the answer to my first question. Not like "I'd better make it different..." (this is not interesting to me how any other developer would make it different - I'll not accept this kind of answer) - but please answer like "this will work without problem" or "this will not work because of the reason......". And explain the reason why this cannot work - when, where, and why.
-
I mean you shouldn't consider plugin as one class, you should consider it as subsystem with own infrastructure. And plugin class can be only loader for this infrastructure.
If plugin will communicate with other plugins, his should know a bit about these plugins.Good example of work with plugins is Qt Creator app.
-
Ok, I've got your idea. But in my application a plugin - it IS some MAIN class. It IS mandatory by design. Another plugin == another class. Each plugin has one MAIN CLASS and a number of subsidiary. Plugin (or class) does not know anything about other plugins it communicates to. It is connected to others by core app. It only sends or receives signals to slots. As I told before - this all works fine now. This is not a subject to change.
My question was only about: Q_EXPORT_PLUGIN2 macro. Will my design work without problems with all possible future plugins implemented like SomePlugin above?
I told that all other in my design work fine. It works exactly like the entire task needs. Why so you try discuss not what I've asked for but entire working design? Please stick on my first question.
-
You are uncertain about your design for future use.
Vass is an experienced Qt programmer and he wants to share his experience with you and avoid the things you are afraid off. If I were you I would take some time off to think about his suggestions and reconsider your approach.
-
Please answer to my questions as they were.
I'm not care about somebodies experience. Probably my experience can be larger or lesser than others. I just asked a question. Please answer in manner: "this is impossible because of...." or "this can be implemented like......"
I still DID NOT GET an answer to my question about Q_EXPORT_PLUGIN2 macro. Is there anybody who knows better how it exactly works?
-
This is how it works:
@define Q_EXPORT_PLUGIN2(PLUGIN, PLUGINCLASS) \
Q_PLUGIN_VERIFICATION_DATA \ Q_EXTERN_C Q_DECL_EXPORT \ const char * Q_STANDARD_CALL qt_plugin_query_verification_data() \ { return qt_plugin_verification_data; } \ Q_EXTERN_C Q_DECL_EXPORT QT_PREPEND_NAMESPACE(QObject) * Q_STANDARD_CALL qt_plugin_instance() \ Q_PLUGIN_INSTANCE(PLUGINCLASS)@
@define Q_PLUGIN_VERIFICATION_DATA \
static const char qt_plugin_verification_data[] = \ "pattern=""QT_PLUGIN_VERIFICATION_DATA""\n" \ "version="QT_VERSION_STR"\n" \ "debug="QPLUGIN_DEBUG_STR"\n" \ "buildkey="QT_BUILD_KEY;@
@
#define Q_PLUGIN_INSTANCE(IMPLEMENTATION)
{
static QT_PREPEND_NAMESPACE(QPointer)<QT_PREPEND_NAMESPACE(QObject)> _instance;
if (!_instance)
_instance = new IMPLEMENTATION;
return _instance;
}
@
So, it's basically just a Singleton of your Plugin. -
Gourmand, please pardon me if I misunderstand your question, but are you basically asking if having the Q_EXPORT_PLUGIN2 macro in a base class for all the plugins is sufficient for doing registration of any child classes that might inherit from it?
If so, I don't believe it is. I think that anyone who would create a subclass of your base class would still have to export their own plugin with its own specific information. Additionally, I'm pretty sure that Q_EXPORT_PLUGIN2 in the base class may cause troubles if it were registered multiple times and/or because it refers to a pure virtual class.
In short, I don't think you can write code which prevents future developers from having to understand some of the Qt nuances. It seems like you're saying "Even though these things are intrinsically Qt plugins, I want to make sure that nobody has to know they're writing Qt plugins."
I may be wrong. (I'm not a huge plugin expert, by any means.) That's just my take on it, though.
-
[quote author="Gourmand" date="1313184854"]Unfortunately no one Qt-inside engineer still did not answered. I have only test it by myself.[/quote]
There's absolutely no sense in complaining that a Qt-inside engineer did not answer your question. We are all volunteers here from all across the Qt community. And from what I've seen, everyone sincerely makes a good attempt to answer your questions to the best of their abilities.
If you truly want an official answer, in a timely manner, from someone who will drop everything to help, then I strongly suggest you visit "Digia":http://qt.digia.com/ and invest in a commercial Qt license or a technical support license.
-
[quote author="Gourmand" date="1313184854"]Unfortunately no one Qt-inside engineer still did not answered. I have only test it by
myself.[/quote]
They probably never will (Both because most of them don't read this forum and they probably have better things to do).Also, I understood your question differently from mlong. He's is right, there can only be one Q_EXPORT_PLUGIN2 per plugin (sorry, If that caused any confusion, I might have misunderstood your intentions)
-
Ok, listen, we're all doing this for free, here and we are trying to help. Nobody guaranteed you that you will get an answer, and nobody is forced to do anything here (again, we are no getting paid for this).
To answer your question: NO, not in all instances!
This will be my last post to this thread.
-
I think you misunderstood the nature of these forums. They are community-driven, supported by people how spend their spare time to help others. This is not an official Qt support forum. If you need definite Qt support you will need to buy a commercial license.
The terms and conditions you signed when creating your account allow you to post any question or discussion topic covered by the posting rules. The same applies for everybody else responding to your questions. They decide if and how to post to this topic, not you.
Receiving an official answer here is not a must nor a right. Receiving any answer here is not a must nor a right. You probably should keep that in mind.
As to your question. I think it already has been answered.
