J'ai l'impression que ton système a pas mal de petit soucis 🙂
Bon, pour que tu comprennes de quoi on parle, je vais essayer d'expliquer un peu le mécanisme de ce script.
Il est écrit en python, avec pour gérer l'interface graphique, glade2script.
glade2script est un soft que j'ai écrit qui permet de communiquer avec l'interface graphique facilement depuis n'importe quel langage, il est écrit en pygtk (python et glade).
Comment ca fonctionne:
Le fichier Test.py est le script par lui même, il communique avec glade2script via le stdout (tous les print "TREE@@',etc,etc).
Glade2script, lui, envois les infos au script via un FIFO (dans la console on a le retour, DEBUG => FIFO write ...)
Dans glade2script, j'ai mis une protection, CAD que si le script (ici Test.py) envois sur le stdout une variable vide (donc un blanc), je ferme ce script (protection en cas de boucle mal foutu, ca evite l'emballement de la machine)
Suite au problème rencontré ici, j'ai modifié un peu glade2script en autorisant 3 blanc venant du script avant de quitter.
MAintenant, chez toi le problème est que l'ouverture d'un fichier envois des erreurs avec des blancs en plus (ce sont des sauts de ligne mais interprété par glade2script comme un blanc).
On comprends mieux le log maintenant:(jai un peu commenté)
# ici tu as appuyé sur return, donc la fonction treeview1 est appelée.
# on ouvre le fichier.
DEBUG => FIFO write: treeview1 clicked
# reponse du script
DEBUG=>: in thread py in_NOT_GET clicked
DEBUG => FIFO write: window1 release@Return #ici la touche return est relachée, l'info n'est pas traitée
DEBUG=>: in thread py in_NOT_GET release@Return
#premier blanc venant du script
DEBUG=>: in thread py
#erreur gedit lors de l'ouverture
DEBUG=>: in thread py (gedit:1837): GLib-GObject-WARNING **: invalid (NULL) pointer instance
# 2 blanc
DEBUG=>: in thread py
#erreur gedit
DEBUG=>: in thread py (gedit:1837): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
# 3 blanc
DEBUG=>: in thread py
#ici Test.py est fermé, en console on n'a plus que les instructions venant de glade2script, plus de réponse du script
DEBUG => FIFO write: window1 press@Left
DEBUG => FIFO write: window1 release@Left
DEBUG => FIFO write: window1 press@Left
DEBUG => FIFO write: window1 release@Left
DEBUG => FIFO write: window1 press@Left
DEBUG => FIFO write: window1 release@Left
DEBUG => FIFO write: window1 press@Alt_L
DEBUG => FIFO write: window1 release@Alt_L
DEBUG => FIFO write: window1 press@Alt_L
Pour régler ce problème,
2 solutions possibles, soit modifier glade2script, soit modifier le script.
Si on veut
modifier glade2script
(glade2script.py) ligne 914 dans la fonction run()
if self.n_break==3 : break
On modifie le 3 en 10 par exemple (ce que je ferais par défaut), donc glade2script acceptera 10 blanc avant de fermer le script.
Ou si on veut
modifier le script, il suffit de ne plus envoyer les erreurs sur la sortie standard.
(Test.py) ligne 199 dans la fonction treeview1, on remplace:
else: subprocess.call(['gnome-open', self.path_fichier])
par:
else: subprocess.call(['gnome-open', self.path_fichier], stderr=subprocess.PIPE)
On envois les messages d'erreur dans un PIPE, donc plus à l'affichage.
Tu peux modifier l'un ou l'autre (ou les 2 même), mais il serait mieux de modifier glade2script pour avoir qd même un retour en console en cas d'erreur lors de l'ouverture d'un fichier.
Voilà, le problème est cerné ... J'espère 🙂
Pour le ctrl+p, il marche pas "très bien". dès fois il désactive correctement, pareil pour la réactivation.
Arff, chez moi ca va nickel ... Tu prends bien le temps entre l'appui de chaque touche, CTRL puis P
Sinon, tu penses que ca vaut le coût de continuer le développement, tu te rends un peu mieux compte des possibilités.
En tout cas, ca n'aura pas été du temps de perdu, j'ai ajouter des commandes à glade2script et trouver qqles bugs en plus de celui-ci 🙂
PS: A partir de ce soir et pendant 1 voir 2 semaines, je n'aurais pas beaucoup de temps à consacrer au dev, un truc imprévu ...
