Discussion :

[white_tentacle]

Bonjour,

J’ai un soucis que je rencontre en faisant interagir du code C++ et du QML.

Quand je déclare un signal QML, tout va bien :

Code :

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

1
2
 
signal unSignal(int unParametre);

Côté C++, pas de soucis pour une connexion avec un slot void(int).

Par contre, pour les slots QML :

Code :

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

1
2
 
function unSlot(unArg /* qui est un int */) { … }

Problème : je ne peux connecter cela qu’avec un signal(QVariant), mais j’aimerais le connecter avec un signal(int).

Y a-t-il moyen de préciser côté QML la signature réelle de mon slot, afin de pouvoir faire les connexions comme il se doit et sans passer par des QVariant (je me fiche que ça utilise des QVariant en interne, je souhaiterai par contre ne pas dégrader la signature de tous mes signaux ou me taper des adaptateurs juste pour ça) ?

[Amnell]

Bonjour,

Ici, on parle de fonction JavaScript et de signal QML. Le fait de déclarer deux signaux avec le même nom est censé déclencher une erreur.

Pour un signal nommé "unSignal", le "slot" est le suivant :

Code :

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

1
2
3
4
5
6
ItemQuelconque {
    // ...
    signal unSignal(string value)
    // ...
    onUnSignal: { doSomething(value); }
}

Après, à ce niveau, value est considéré comme étant de type string, si je ne me trompe pas. Sinon, il y a toujours moyen de faire String(value).

Bonne continuation,
Amnell.

[white_tentacle]

Bonjour,

Ici, on parle de fonction JavaScript et de signal QML.

Merci, mais ça ne répond pas vraiment à mon problème .

Sur mon composant Qml, si je déclare une fonction javascript, elle est automatiquement disponible comme slot. Problème : ses arguments ne sont pas typés. Alors pour les signaux il y a une syntaxe qui permet de typer…

Code :

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

1
2
3
4
5
6
7
 
Item
{
   function unSlot(arg)
   { … }
   signal valueChanged(int theValue);
}

et côté cpp :

Code C++ :

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

1
2
3
4
5
6
7
8
9
10
 
class Toto
{
…
public slots:
   void autreSlot(int);
signals:
   void sig1(int);
   void sig2(QVariant);
}

Code C++ :

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

1
2
3
4
5
6
 
/* item est une référence vers mon item Qml */
QObject::connect(item, SIGNAL(valueChanged(int)), toto, SLOT(autreSlot(int))); // OK
QObject::connect(toto, SIGNAL(sig1(int)), item, SLOT(unSlot(int))); // NOK : no such slot (1)
QObject::connect(toto, SIGNAL(sig1(int)), item, SLOT(unSlot(QVariant))); // NOK : signatures incompatibles (2)
QObject::connect(toto, SIGNAL(sig2(QVariant)), item, SLOT(unSlot(QVariant))); // OK

Mon problème, c’est que j’aimerai un moyen pour que (1) ou (2) fonctionne.

[Amnell]

Bonsoir,

La connexion signal(QVariant) à jsFunction(QVariant) va fonctionner vu que les fonctions QML sont considérées comme prenant en paramètre des QVariant. À savoir que QVariant garde le type() et la value() qu'on lui a assigné, il n'y a aucun risque de perte de données. De là, ce n'est pas possible de faire une connexion en int to QVariant par rapport au système de métaobjets qui n'est pas conçu pour (vu que, si je ne me trompe pas, un connect() travaille avec du char* puis du QMetaObject::invokeMethod() et non directement avec des pointeurs sur fonction - Qt doit donc trouver un moyen de vérifier la validité de la connexion et une compatibilité des arguments).

À noter qu'il n'est pas "propre" de faire une connexion du C++ à une fonction du QML du fait que cela casse complètement la raison pour laquelle QML applique le principe MVC. Ce que je peux vous proposer : Communication entre QML et C++/Qt.

Bonne continuation,
Amnell.

[white_tentacle]

Merci pour la réponse, ce n’est donc bien pas possible.

À noter qu'il n'est pas "propre" de faire une connexion du C++ à une fonction du QML du fait que cela casse complètement la raison pour laquelle QML applique le principe MVC. Ce que je peux vous proposer : Communication entre QML et C++/Qt.

Ok. Perso, je ne vois pas ce que ça casse (j’ai une classe métier, une classe d’interface, et de la glu au milieu, qu’elle soit côté c++ ou qml ne change de mon point de vue conceptuellement pas grand chose), mais si c’est fait pour faire comme ça, autant s’adapter.