Welcome on the EKD bug report site.
FS#41 - Ekd ne se lance pas correctement en arrière plan
Concerne le projet:
EKD
Ouverte par Strict Standards: array_map() expects parameter 1 to be a valid callback, non-static method Filters::noXSS() should not be called statically in /data/web/64/9e/8e/ekd.tuxfamily.org/htdocs/bugs/includes/class.tpl.php on line 281 Ptah (Ptah) - Strict Standards: Non-static method Filters::noXSS() should not be called statically in /data/web/64/9e/8e/ekd.tuxfamily.org/htdocs/bugs/includes/class.tpl.php on line 613 mercredi, 24 février 2010, 20:51 GMT
Dernière édition par Ptah (Ptah) - Strict Standards: Non-static method Filters::noXSS() should not be called statically in /data/web/64/9e/8e/ekd.tuxfamily.org/htdocs/bugs/includes/class.tpl.php on line 613 lundi, 29 mars 2010, 20:24 GMT
Ouverte par Strict Standards: array_map() expects parameter 1 to be a valid callback, non-static method Filters::noXSS() should not be called statically in /data/web/64/9e/8e/ekd.tuxfamily.org/htdocs/bugs/includes/class.tpl.php on line 281 Ptah (Ptah) - Strict Standards: Non-static method Filters::noXSS() should not be called statically in /data/web/64/9e/8e/ekd.tuxfamily.org/htdocs/bugs/includes/class.tpl.php on line 613 mercredi, 24 février 2010, 20:51 GMT
Dernière édition par Ptah (Ptah) - Strict Standards: Non-static method Filters::noXSS() should not be called statically in /data/web/64/9e/8e/ekd.tuxfamily.org/htdocs/bugs/includes/class.tpl.php on line 613 lundi, 29 mars 2010, 20:24 GMT
|
DétailsSous Kde, on est obliger d'ajouter l'option Terminal=False dans le fichier .desktop de ekd.
Sans cette option, ekd ne se lance pas. Visiblement Kde lance ekd en arrière plan, ce qui pose problème. Il y a une incompatibilité entre subprocess.Popen de python et les QApplication. Si le QApplication est mis en arrière plan, les sous process le son également. Pour corriger le problème, il semble que passer tous les subprocess.Popen à des QProcess permet de lancer ekd en arrière plan. |
Cette tâche dépend de
Sous KDE:
Le problème exact est que dans la construction du paquet si on met l'option Terminal=false, au moment de démarrer EKD par Applications > Multimédia --> ekd ... il se lance bien (EKD démarre sans la console en arrière-plan, là c'est normal) mais si on essaye de faire un traitement vidéo et bien RIEN de RIEN --> pas de barre de progression et pas de traitement ! (comme si on avait pas les droits !).
==> Constatation très très importante: les traitements Image se passent bien !!!, les traitements audio semblent bien se passer aussi (il faudrait tout tester) ... MAIS AUCUN DES TRAITEMENTS VIDEO NE PEUT SE FAIRE !!!!!!!!!!!.
Par contre si on démarre EKD en tapant ekd dans le terminal (et toujours à partir du paquet construit avec Terminal=false) et bien tout fonctionne ! (traitements Vidéo, image et Musique-Son).
--> Si on construit le paquet avec l'option Terminal=true (EKD démarre avec la console en arrière-plan, là c'est normal) ... et qu'on démarre EKD par Applications > Multimédia --> ekd ... tout fonctionne parfaitement !!!!.
Il semblerait que EKD démarré sous Gnome ou sous XFCE (et avec le paquet construit avec Terminal=false) n'a pas tous ces problèmes (à vérifier !).
Voilà, voilà.
Visiblement le problème n'est pas vraiment lié à Kde, mais plutôt à la gestion de popen avec les QApplications.
Je suis en train de modifier le code pour prendre en compte ces modifications.
Je ne suis pas pervenu à utiliser QProcess pour parser correctement l'output de ffmpeg.
Donc je continue, quand c'est possible de passer à des QProcess.
Les processus générés pas Popen ne recevaient pas les signaux des parents, voir : http://www.doughellmann.com/PyMOTW/subprocess/ (Partie Process Groups / Sessions)
En ajoutant le paramètre : preexec_fn=os.setsid à l'appel à Popen, on créer un groupe de processus qui partageront les mêmes signaux.
A tester.
Je lis dans le lien que tu viens de donner:
" Because of the way the process tree works under Unix " --> est ce que cela veut dire que preexec_fn=os.setsid ne fonctionnera que sous Linux ?, et pas sous win ?.
Si on arrive à s'en sortir, c'est excellent !.
If preexec_fn is set to a callable object, this object will be called in the child process just before the child is executed. (Unix only)
Je ne sais pas si c'est ignoré sous Windows ou si ça provoque une erreur.
Il faudrait le tester, mais je pense que l'option est ignorée.
J'ai créé une fonction permettant de gérer ces problèmes de codage pour les messages affichés sur la console :
debug(message).
C'est, je l'espère, le dernier problème sur ce bug.
Il faut confirmer que la correction faite dans la révision 976 résoud le problème.
Il faudrait certainement éviter d'utiliser les exceptions avec :
try :
....
except Exception :
....
Car dans ce cas toutes les exception sont interceptées y compris celle qui a provoqué le problème.
Il faudrait selectionner les Exceptions qui nous interressent plutôt que de toute les intercepter.