Les avantages et inconvénients du pyqtSignal

Bonjour à tous

Concernant le mécanisme signal/slot de PyQt, je suis peu à peu passé de l'ancienne version (Signal) à la nouvelle (pyqtSignal). Toutefois tout ne me plait pas forcément dans cette façon de procéder...

Prenons par exemple un widget personnalisé qui va envoyer un signal "toto" et connectons-le à un widget parent.

Dans l'ancienne version, cela se faisait plus ou moins de cette façon

Code:

---

1 2 3

class myWidget(QWidget): def action(): self.emit(SIGNAL("toto"))

---

Et la connection:

Code:

---

1 2 3 4 5 6 7 8

wid=myWidget() QObject.connect( wid, SIGNAL("toto"), traitementToto, )   def traitementToto(): ...

---

Avec le pyqtSignal, cela se fait maintenant de cette façon:

Code:

---

1 2 3 4

class myWidget(QWidget): sigToto=pyqtSignal() def action(): self.sigToto.emit()

---

Et la connection:

Code:

---

1 2 3 4 5

wid=myWidget() wid.sigToto.connect(traitementToto)   def traitementToto(): ...

---

Alors effectivement l'écriture de la connection dans la nouvelle version devient plus aisée. Mais on ne peut plus créer de signal "en live" dans notre objet. On est obligé de créer une variable statique, bien repérer son nom pour pas la louper à la connection et etc etc etc. Bref un peu de contraintes en plus.

Donc j'aurais aimé avoir vos avis sur cette nouvelle façon de procéder.

Merci à tous.

Bonjour Sve@r

Curieusement, il y a tellement longtemps que j'utilise le nouveau codage des signaux PyQt5 que je ne vois plus bien la différence par rapport à l'ancien codage. Mais en tout cas, le nouveau codage me convient très bien, et je l'utilise souvent. Je ne sais pas ce que tu entends par <créer de signal "en live"> mais s'il s'agit de créer un nouveau signal pendant l'exécution, je n'en ai jamais eu besoin.

J'utilise beaucoup les signaux avec les threads. Cela permet de pouvoir informer sans retard le programme principal qu'une opération asynchrone est terminée, ou de lui envoyer des infos au moment où celles-ci sont disponibles. Par exemple pour une opération longue comme un calcul ou un téléchargement FTP, on peut utiliser une barre de progression, ou même un simple "throbber" (une petite roue qui tourne) comme ici: http://python.jpvweb.com/python/mesr...pyqt5_throbber. Cela fait que j'utilise une classe héritant de QThread le plus souvent pour ça (ou une classe héritant en même temps de threading et de QObject).

J'utilise aussi les signaux pour informer une fenêtre qu'une de ses fenêtres "filles" vient de se fermer ou vient de lui renvoyer des infos. Etc...

Il m'arrive souvent d'utiliser les décorateurs "QtCore.pyqtSlot" pour préciser les méthodes Python pris en tant que "slots", avec les types d'arguments transmis parce que cela facilite la liaison entre Python et Qt5.

Je suis cependant loin d'utiliser toutes les subtilités des signaux PyQt5 telles que décrites ici: https://www.riverbankcomputing.com/s...als_slots.html. Mais j’apprécie beaucoup l'élégance du code que ces signaux permettent.

Salyt tyrtamos. Merci de ton avis

Citation:

---

Envoyé par tyrtamos

Je ne sais pas ce que tu entends par <créer de signal "en live"> mais s'il s'agit de créer un nouveau signal pendant l'exécution, je n'en ai jamais eu besoin.

---

C'est un peu ça. Comment dire...
Dans ma première version, le signal "toto" n'est pas connu de l'objet avant qu'il soit émis par la méthode "action". C'est en quelque sorte ce que j'appelle "live". Je l'émet au moment où j'en ai besoin dans la conception de mon objet.
Dans la seconde version, je suis obligé de créer une variable statique "sigToto" pour pouvoir l'émettre. Ce n'est plus de l'impromptu. Création d'une variable même si celle-ci n'est utilisée qu'une fois ce qui va un peu à l'encontre de certains réflexes. Ca me gêne autant que si j'écrivais

Code:

---

1 2 3

def carre(x): a=x**2 return a

---

...

Merci pour ton lien "throbber". J'adore !!! :applo:

Citation:

---

Envoyé par tyrtamos

Il m'arrive souvent d'utiliser les décorateurs "QtCore.pyqtSlot" pour préciser les méthodes Python pris en tant que "slots", avec les types d'arguments transmis parce que cela facilite la liaison entre Python et Qt5.

---

Tu veux bien préciser ce point ? Parce que je ne vois pas trop la différence entre

Code:

---

1 2 3 4 5

wid=myWidget() wid.sigToto.connect(traitementToto)   def traitementToto(): ...

---

et

Code:

---

1 2 3 4 5 6

wid=myWidget() wid.sigToto.connect(traitementToto)   @pyqtSlot() def traitementToto(): ...

---

???

Citation:

---

Envoyé par Sve@r

Tu veux bien préciser ce point ? Parce que je ne vois pas trop la différence entre

Code:

---

1 2 3 4 5

wid=myWidget() wid.sigToto.connect(traitementToto)   def traitementToto(): ...

---

et

Code:

---

1 2 3 4 5 6

wid=myWidget() wid.sigToto.connect(traitementToto)   @pyqtSlot() def traitementToto(): ...

---

???

---

Je me suis contenté d'appliquer ce qui est marqué dans la doc (et je lis même la doc des appareils électroménagers: tu vois à quel point je suis anormal... :roll:). A priori, toutes les méthodes Python sont capables d'être utilisées comme slots, mais en utilisant le décorateur pyqtSlot, on a quelques avantages de mémoire et de vitesse. Extrait de la doc:

Citation:

---

Connecting a signal to a decorated Python method also has the advantage of reducing the amount of memory used and is slightly faster.

---

(https://www.riverbankcomputing.com/s...slot-decorator)

C'est tout à fait optionnel, mais ça ne coûte pas cher à ajouter... Attention cependant: dans les dernières versions de PyQt5, une erreur de type d'argument dans pyqtSlot génère une exception.

Salut,

Citation:

---

Envoyé par Sve@r

Donc j'aurais aimé avoir vos avis sur cette nouvelle façon de procéder.

---

Un signal est une interface qui va permettre à deux objets l'échange de messages de façon un peu particulière et adaptée aux activités asynchrones.
Comme toute interface, le client (un des 2 objets) doit savoir comment l'utiliser (et le récepteur comment y réagir).
Vu comme çà, le fait que ce soit statique (comme la définition d'une méthode) ne me gène pas plus que çà.
note: Si la définition d'une méthode est "statique" rien n'empêche la création de classes dynamiquement (via type(...)). Donc s'il y a besoin (à préciser), on peut toujours faire et simplifier (en cacher les détails).

- W

Citation:

---

Envoyé par tyrtamos

(et je lis même la doc des appareils électroménagers: tu vois à quel point je suis anormal... :roll:)

---

Ah c'est toi !!!
Effectivement sur le forum de wh...ool il est écrit qu'il y a quelqu'un qui lit la doc et ils cherchaient qui c'était...:ptdr:

Citation:

---

Envoyé par tyrtamos

mais ça ne coûte pas cher à ajouter...

---

Ben... je viens de balayer tous mes sources concernant mes projets les plus en cours. 309 slots se répartissants sur 128 sources auquel j'ai rajouté @pyqtSlot() modulo le/les paramètres dudit slot... J'y ai passé 2h quand-même...:calim2:

Citation:

---

Envoyé par wiztricks

Comme toute interface, le client (un des 2 objets) doit savoir comment l'utiliser (et le récepteur comment y réagir).

---

Oui c'est vai que j'ai un peu exagéré en disant que c'était du "live" :oops: Fatalement si X emet "toto", il faut que Y sache qu'il se nomme "toto" pour le connecter donc il y a quelque part un travail de préparation à effectuer.

Citation:

---

Envoyé par wiztricks

Vu comme çà, le fait que ce soit statique (comme la définition d'une méthode) ne me gène pas plus que çà.

---

Bon le pyqtSignal je m'y fais à force. Mais je ne dis pas que ça ne me crispe pas un petit peu quand je suis en train de coder l'action et que je dois repartir au début de mon objet pour le définir (oui, moi aussi je suis un peu maniaque et j'aime bien définir mes attributs statiques au début de l'objet).

Merci de ton avis 8-)