Discussion :

[RapotOR]

Bonjour,

J'aimerais effectuer des échanges bidirectionnels de données entre une application et ses plugins. Les plugins sont gérés par le système Qt avec PluginLoader. C'est typiquement le cas pour créer des plugins d'import ou d'export de donnés.

Auriez vous de bonnes pratiques sur le sujet?

Voici deux solutions que j ai envisagées; qu'en pensez vous de celles-ci sachant qu'il faut ensuite les adapter à l’échange bidirectionnel?


1/le système des SIGNALS/SLOTS pour récupérer des données d'un plugin:

Donc l interface pour les plugins comme ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
class ImportInterface : public QObject
{
    Q_OBJECT
 
public:
    explicit ImportInterface() : QObject(0) {}
 
    virtual bool getData(double *data) = 0;
 
signals:
    void dataReady(int size);
 
};

Ainsi, je connecte mon application au signal de l'instance du plugin lors de son initialisation.
Lorsque le plugin émet le signal dataReady, l'application récupère les données via getData.

Par ce moyen, la logique n'est pas exposée. Seul le fichier header du plugin est nécessaire pour créé un nouveau plugin. Cette solution a ma préférence.


2/ J'ai lu l’idée de fournir une classe commune à l'application et au plugin; un espèce de bridge.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
class ImportInterface : public QObject
{
    Q_OBJECT
 
public:
    explicit ImportInterface() : QObject(0) {}
 
    virtual bool initialize(AppBridge *applicationBridge) = 0;
 
protected:
     AppBridge *bridge;
 
};

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
class AppBridge: public QObject
{
    Q_OBJECT
 
public:
    explicit AppBridge(QObject *parent) : QObject(parent) {}
 
    void getData(double* data, int *size);
    void setData(double* data, int size);
 
protected:
     double *data;
     int size;
 
};

Par ce biais, il est possible d'heriter AppBridge dans l'application et de recuperer les donnes via la variable qui est située dans la classe Mere AppBridge.

Dans l application, cela donnerait quelque chose comme ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
AppBridge *applicationSide = new AppBridge(app);
myPlugin->initialize(applicationSide);

Merci pour vos avis sur le sujet.

Cordialement,

[yan]

Salut.
si je me souviens bien comment fonctionne les plugin de Qt l'interface est forcement une classe abstraite et ne peux être un QObject.

Dans ton cas

• Solution 1 : elle t'oblige à connaitre les signal/slots du plugin de l'instance de ton plugin.
• Solution 2 : tu pourrais directement passer un QObject et laisser le plugin créer les connexions.

Autre solution : ton plugin est une factory qui te permet d'instancier un QObject dont les signal/slot sont spécifier dans un classe mère.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
class ObjetPlugin 
: public QObject
{
    Q_OBJECT
 
public:
    ObjetPlugin (QObject * parent = 0) : QObject(parent) {}
slot :
 void un slot();
 
signals:
    void unSignal();
 
};
...
 
class FactoryInterface 
{
public:
   ObjetPlugin  * CreerInstance(QObject * parent = 0) = 0;
 
};

[RapotOR]

La classe abstraite en QObject fonctionne (sous Qt5 du moins).
Donc, la solution 1 et la solution 3 sont équivalentes au niveau du lien.
Merci pour ton intervention.

[yan]

Salut j'ai dit une connerie
Je suis revenue sur un projet (date de 2-3 ans) où j'ai mis en place des plugins. Et tu peux sans problème faire une interface plugin avec QObject.
Je me suis mélangé les pinceaux .

Dans mon cas, j'ai fait ta solution 1 et je fait un qobject_cast pour retrouver à quelle interface correspond l'instance. Puis je connecte en conséquence.

La solution 3 à pour seule avantage la possibilité d'avoir plusieurs instances distinct.

Yan