[WxPython] comment éviter le multi-threading avec GUI
14 réponses
N. Pourcelot
Bonjour,
je suis confronté au problème suivant sous WxPython.
Je veux pouvoir lancer des animations graphiques dans le Panel.
Basiquement, j'ai par exemple un objet A, avec des attributs x et y, et
j'ouvre dans mon programme un fichier qui contient un truc du genre :
for i in range(90):
A.x += 0.1
A.y -= 0.1
J'exécute le code contenu dans le fichier, et mon objet A se déplace.
Seul problème : mon programme est bloqué pendant ce temps ; si mon
script d'animation est un peu long, c'est embêtant.
J'ai pensé exécuter le code dans un thread auxiliaire, ça marche bien
sous Windows, mais sous Linux, le serveur X n'aime pas ça du tout.
("Xlib: unexpected async reply")
De manière générale, j'ai lu qu'il était déconseillé de toucher à tout
ce qui est GUI quand on fait du multi-threading, surtout avec le serveur X.
http://www.faqs.org/faqs/x-faq/part7/section-15.html
Cela dit, je ne vois pas trop comment contourner le problème.
Dans le dernier lien, je lis ("being sure to enable Xlib's multi-thread
support")
Comment je peux faire ça (dynamiquement) depuis WxPython ?
Sinon, comment parvenir au même résultat sans utiliser de threads (j'ai
souvent lu ce conseil aussi) ??
J'ai compris Yield comme étant une méthode de wxApp qui permet de laisser respirer le système de temps en temps quand on fait une boucle.
wx.Yield est une fonction (wx.App n'a pas de méthode Yield) qui gère tous les évenements wx en attente.
Je ne vois pas le rapport avec ce qui nous occupe !
Citons donc l'auteur du sujet :
Seul problème : mon programme est bloqué pendant ce temps
loufoque
Désolé cher ami, il y a bien une classe wx.Threads
C'est moi qui suis désolé pour vous qui ne savez malheureusement pas lire mes propos. wxThread existe (C++), mais pas wx.Thread (Python) cf. http://www.wxpython.org/docs/api/
Autrement dit, il n'y a pas de proxy/wrapper Python pour cette classe, étant donné qu'elle est inutile en Python. (C'est aussi le cas de bien d'autres classes étant donné que wxwidgets est un framework de programmation complet, qui définit les listes, les chaînes, les sockets, les regexes, etc.)
Désolé cher ami, il y a bien une classe wx.Threads
C'est moi qui suis désolé pour vous qui ne savez malheureusement pas
lire mes propos.
wxThread existe (C++), mais pas wx.Thread (Python)
cf. http://www.wxpython.org/docs/api/
Autrement dit, il n'y a pas de proxy/wrapper Python pour cette classe,
étant donné qu'elle est inutile en Python.
(C'est aussi le cas de bien d'autres classes étant donné que wxwidgets
est un framework de programmation complet, qui définit les listes, les
chaînes, les sockets, les regexes, etc.)
Désolé cher ami, il y a bien une classe wx.Threads
C'est moi qui suis désolé pour vous qui ne savez malheureusement pas lire mes propos. wxThread existe (C++), mais pas wx.Thread (Python) cf. http://www.wxpython.org/docs/api/
Autrement dit, il n'y a pas de proxy/wrapper Python pour cette classe, étant donné qu'elle est inutile en Python. (C'est aussi le cas de bien d'autres classes étant donné que wxwidgets est un framework de programmation complet, qui définit les listes, les chaînes, les sockets, les regexes, etc.)
jean-michel bain-cornu
loufoque wrote:
J'ai compris Yield comme étant une méthode de wxApp qui permet de laisser respirer le système de temps en temps quand on fait une boucle.
wx.Yield est une fonction (wx.App n'a pas de méthode Yield) qui gère tous les évenements wx en attente. Pardon d'avoir heurté votre rigueur. J'insiste, Yield est bien membre de
wxAPP ; savoir si c'est une méthode ou une fonction... Les experts ont leur mot à dire en sachant qu'il ne suffit pas d'affirmer pour avoir raison. Par ailleurs, je suis prêt à parier que l'exécution de Yield sans création préalable d'un objet App provoquera une exception, précisément parce que cette fonction/méthode n'a pas de sens sans un objet App dont la création est obligatoire avant tout autre objet wx (chapitre 5, A first application : 'hello world')
Je ne vois pas le rapport avec ce qui nous occupe !
Citons donc l'auteur du sujet :
Seul problème : mon programme est bloqué pendant ce temps
J'insiste encore, yield ne gère pas les évènements en attente, mais rend
la main au système pour lui permettre de continuer à gérer ses évènements (la doc cite windows 3 qui a besoin de ça pour pouvoir continuer à faire tourner les autres process), ce qui par parenthèse peut provoquer un plantage si l'on crée une boucle (car on est *déjà* en train de gérer un évènement qd on fait un yield). Le programme est bloqué dans le cas qui nous occupe simplement parce qu'il est occupé à boucler pour bouger un widget. Comme décidément je ne comprends pas, pourriez-vous me donner un peu plus d'explications sur votre concept ? A+ jm
loufoque wrote:
J'ai compris Yield comme étant une méthode de wxApp qui permet de
laisser respirer le système de temps en temps quand on fait une boucle.
wx.Yield est une fonction (wx.App n'a pas de méthode Yield) qui gère
tous les évenements wx en attente.
Pardon d'avoir heurté votre rigueur. J'insiste, Yield est bien membre de
wxAPP ; savoir si c'est une méthode ou une fonction... Les experts ont
leur mot à dire en sachant qu'il ne suffit pas d'affirmer pour avoir raison.
Par ailleurs, je suis prêt à parier que l'exécution de Yield sans
création préalable d'un objet App provoquera une exception, précisément
parce que cette fonction/méthode n'a pas de sens sans un objet App dont
la création est obligatoire avant tout autre objet wx (chapitre 5, A
first application : 'hello world')
Je ne vois pas le rapport avec ce qui nous occupe !
Citons donc l'auteur du sujet :
Seul problème : mon programme est bloqué pendant ce temps
J'insiste encore, yield ne gère pas les évènements en attente, mais rend
la main au système pour lui permettre de continuer à gérer ses
évènements (la doc cite windows 3 qui a besoin de ça pour pouvoir
continuer à faire tourner les autres process), ce qui par parenthèse
peut provoquer un plantage si l'on crée une boucle (car on est *déjà* en
train de gérer un évènement qd on fait un yield).
Le programme est bloqué dans le cas qui nous occupe simplement parce
qu'il est occupé à boucler pour bouger un widget.
Comme décidément je ne comprends pas, pourriez-vous me donner un peu
plus d'explications sur votre concept ?
A+
jm
J'ai compris Yield comme étant une méthode de wxApp qui permet de laisser respirer le système de temps en temps quand on fait une boucle.
wx.Yield est une fonction (wx.App n'a pas de méthode Yield) qui gère tous les évenements wx en attente. Pardon d'avoir heurté votre rigueur. J'insiste, Yield est bien membre de
wxAPP ; savoir si c'est une méthode ou une fonction... Les experts ont leur mot à dire en sachant qu'il ne suffit pas d'affirmer pour avoir raison. Par ailleurs, je suis prêt à parier que l'exécution de Yield sans création préalable d'un objet App provoquera une exception, précisément parce que cette fonction/méthode n'a pas de sens sans un objet App dont la création est obligatoire avant tout autre objet wx (chapitre 5, A first application : 'hello world')
Je ne vois pas le rapport avec ce qui nous occupe !
Citons donc l'auteur du sujet :
Seul problème : mon programme est bloqué pendant ce temps
J'insiste encore, yield ne gère pas les évènements en attente, mais rend
la main au système pour lui permettre de continuer à gérer ses évènements (la doc cite windows 3 qui a besoin de ça pour pouvoir continuer à faire tourner les autres process), ce qui par parenthèse peut provoquer un plantage si l'on crée une boucle (car on est *déjà* en train de gérer un évènement qd on fait un yield). Le programme est bloqué dans le cas qui nous occupe simplement parce qu'il est occupé à boucler pour bouger un widget. Comme décidément je ne comprends pas, pourriez-vous me donner un peu plus d'explications sur votre concept ? A+ jm
jean-michel bain-cornu
loufoque wrote:
Désolé cher ami, il y a bien une classe wx.Threads
C'est moi qui suis désolé pour vous qui ne savez malheureusement pas lire mes propos. wxThread existe (C++), mais pas wx.Thread (Python) cf. http://www.wxpython.org/docs/api/ En toute rigueur, le '.' était de trop je vous l'accorde, bien que les
deux terminologies soient valables en python. Le fait que wxThread ne soit pas implémenté nativement en wxpython n'empêche pas de l'utiliser en python. Mon but était de donner un coup de main à l'initiateur du fil. Après réflexion, utiliser wxThread pour résoudre son pb est bien un troll, mais parce que c'est trop compliqué à faire, pas parce que ça n'existe pas !
Autrement dit, il n'y a pas de proxy/wrapper Python pour cette classe, étant donné qu'elle est inutile en Python. Rien n'empêche d'en écrire un si ça en vaut la peine.
(C'est aussi le cas de bien d'autres classes étant donné que wxwidgets est un framework de programmation complet, qui définit les listes, les chaînes, les sockets, les regexes, etc.) Il y a pourtant des cas ou le double emploi existe, et est même hélas
nécessaire, comme par exemple avec datetime/wx.DateTime .
loufoque wrote:
Désolé cher ami, il y a bien une classe wx.Threads
C'est moi qui suis désolé pour vous qui ne savez malheureusement pas
lire mes propos.
wxThread existe (C++), mais pas wx.Thread (Python)
cf. http://www.wxpython.org/docs/api/
En toute rigueur, le '.' était de trop je vous l'accorde, bien que les
deux terminologies soient valables en python.
Le fait que wxThread ne soit pas implémenté nativement en wxpython
n'empêche pas de l'utiliser en python.
Mon but était de donner un coup de main à l'initiateur du fil. Après
réflexion, utiliser wxThread pour résoudre son pb est bien un troll,
mais parce que c'est trop compliqué à faire, pas parce que ça n'existe pas !
Autrement dit, il n'y a pas de proxy/wrapper Python pour cette classe,
étant donné qu'elle est inutile en Python.
Rien n'empêche d'en écrire un si ça en vaut la peine.
(C'est aussi le cas de bien d'autres classes étant donné que wxwidgets
est un framework de programmation complet, qui définit les listes, les
chaînes, les sockets, les regexes, etc.)
Il y a pourtant des cas ou le double emploi existe, et est même hélas
nécessaire, comme par exemple avec datetime/wx.DateTime .
Désolé cher ami, il y a bien une classe wx.Threads
C'est moi qui suis désolé pour vous qui ne savez malheureusement pas lire mes propos. wxThread existe (C++), mais pas wx.Thread (Python) cf. http://www.wxpython.org/docs/api/ En toute rigueur, le '.' était de trop je vous l'accorde, bien que les
deux terminologies soient valables en python. Le fait que wxThread ne soit pas implémenté nativement en wxpython n'empêche pas de l'utiliser en python. Mon but était de donner un coup de main à l'initiateur du fil. Après réflexion, utiliser wxThread pour résoudre son pb est bien un troll, mais parce que c'est trop compliqué à faire, pas parce que ça n'existe pas !
Autrement dit, il n'y a pas de proxy/wrapper Python pour cette classe, étant donné qu'elle est inutile en Python. Rien n'empêche d'en écrire un si ça en vaut la peine.
(C'est aussi le cas de bien d'autres classes étant donné que wxwidgets est un framework de programmation complet, qui définit les listes, les chaînes, les sockets, les regexes, etc.) Il y a pourtant des cas ou le double emploi existe, et est même hélas
nécessaire, comme par exemple avec datetime/wx.DateTime .
