Une fois que new() est appel=E9e, le script n'a plus du tout la main, je
pense que c'est =E0 cause de MainLoop (je ne peux pas par exemple
appeler 'destroy' sur la classe). Je n'ai jamais utilis=E9 de thread
mais je pense que c'est le moyen de 'piloter' cette cette classe.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Paul Gaborit
À (at) 27 Sep 2006 08:00:30 -0700, "ctobini" écrivait (wrote):
Je voudrais créer un petit package afin de faire une barre de progression en Tk, je bute sur une chose : [...]
Une fois que new() est appelée, le script n'a plus du tout la main, je pense que c'est à cause de MainLoop (je ne peux pas par exemple appeler 'destroy' sur la classe). Je n'ai jamais utilisé de thread mais je pense que c'est le moyen de 'piloter' cette cette classe.
Pourriez-vous m'en dire plus là-dessus ?
Première chose : il est risqué voire impossible de faire un fork depuis une application Tk (en tous cas dans l'implémentation actuelle) sauf si on il est suivi immédiatement d'un 'exec' (côté fils). Pour les threads, je n'en sais rien.
Ce qu'il est possible de faire :
1 - le processus Père prépare la tâche (sans Tk)
2 - Il fait un fork (en thread, je n'ai jamais testé) et le fils charge Tk et crée l'interface.
Après, il faut encore gérer les communications entre le fils et le père. Côté père, c'est du classique (quoique...). Côté fils, il faut demander à Tk de surveiller un filehandle (celui qui communique avec le père) en plus de la surveillance de l'interface.
On peut aussi utiliser une toute autre méthode :
1- créer l'interface en demandant (via 'after') le lancement d'une procèdure juste après l'ouveture de la fenêtre.
2- la procèdure monopolise Perl (qui ne gère donc plus l'interface). Mais si elle fait appel régulièrement à la méthode 'update' de Tk, on peut donner l'impression que l'interface fonctionne.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Je voudrais créer un petit package afin de faire une barre de
progression en Tk, je bute sur une chose :
[...]
Une fois que new() est appelée, le script n'a plus du tout la main, je
pense que c'est à cause de MainLoop (je ne peux pas par exemple
appeler 'destroy' sur la classe). Je n'ai jamais utilisé de thread
mais je pense que c'est le moyen de 'piloter' cette cette classe.
Pourriez-vous m'en dire plus là-dessus ?
Première chose : il est risqué voire impossible de faire un fork
depuis une application Tk (en tous cas dans l'implémentation actuelle)
sauf si on il est suivi immédiatement d'un 'exec' (côté fils). Pour
les threads, je n'en sais rien.
Ce qu'il est possible de faire :
1 - le processus Père prépare la tâche (sans Tk)
2 - Il fait un fork (en thread, je n'ai jamais testé) et le fils
charge Tk et crée l'interface.
Après, il faut encore gérer les communications entre le fils et le
père. Côté père, c'est du classique (quoique...). Côté fils, il faut
demander à Tk de surveiller un filehandle (celui qui communique avec
le père) en plus de la surveillance de l'interface.
On peut aussi utiliser une toute autre méthode :
1- créer l'interface en demandant (via 'after') le lancement d'une
procèdure juste après l'ouveture de la fenêtre.
2- la procèdure monopolise Perl (qui ne gère donc plus
l'interface). Mais si elle fait appel régulièrement à la méthode
'update' de Tk, on peut donner l'impression que l'interface
fonctionne.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) 27 Sep 2006 08:00:30 -0700, "ctobini" écrivait (wrote):
Je voudrais créer un petit package afin de faire une barre de progression en Tk, je bute sur une chose : [...]
Une fois que new() est appelée, le script n'a plus du tout la main, je pense que c'est à cause de MainLoop (je ne peux pas par exemple appeler 'destroy' sur la classe). Je n'ai jamais utilisé de thread mais je pense que c'est le moyen de 'piloter' cette cette classe.
Pourriez-vous m'en dire plus là-dessus ?
Première chose : il est risqué voire impossible de faire un fork depuis une application Tk (en tous cas dans l'implémentation actuelle) sauf si on il est suivi immédiatement d'un 'exec' (côté fils). Pour les threads, je n'en sais rien.
Ce qu'il est possible de faire :
1 - le processus Père prépare la tâche (sans Tk)
2 - Il fait un fork (en thread, je n'ai jamais testé) et le fils charge Tk et crée l'interface.
Après, il faut encore gérer les communications entre le fils et le père. Côté père, c'est du classique (quoique...). Côté fils, il faut demander à Tk de surveiller un filehandle (celui qui communique avec le père) en plus de la surveillance de l'interface.
On peut aussi utiliser une toute autre méthode :
1- créer l'interface en demandant (via 'after') le lancement d'une procèdure juste après l'ouveture de la fenêtre.
2- la procèdure monopolise Perl (qui ne gère donc plus l'interface). Mais si elle fait appel régulièrement à la méthode 'update' de Tk, on peut donner l'impression que l'interface fonctionne.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
ctobini
Bonjour et merci de la réponse,
Je vais tenter en premier la méthode suivante :
Ce qu'il est possible de faire :
1 - le processus Père prépare la tâche (sans Tk)
2 - Il fait un fork (en thread, je n'ai jamais testé) et le fils charge Tk et crée l'interface.
Après, il faut encore gérer les communications entre le fils et le père. Côté père, c'est du classique (quoique...). Côté fils, il faut demander à Tk de surveiller un filehandle (celui qui communique avec le père) en plus de la surveillance de l'interface.
J'aurais besoin d'une précision: père et fils gèrent-ils la partie Tk ou le père est en fait le 'main' du script (je n'ai jamais fait de fork) ?
C. Tobini
Bonjour et merci de la réponse,
Je vais tenter en premier la méthode suivante :
Ce qu'il est possible de faire :
1 - le processus Père prépare la tâche (sans Tk)
2 - Il fait un fork (en thread, je n'ai jamais testé) et le fils
charge Tk et crée l'interface.
Après, il faut encore gérer les communications entre le fils et le
père. Côté père, c'est du classique (quoique...). Côté fils, il faut
demander à Tk de surveiller un filehandle (celui qui communique avec
le père) en plus de la surveillance de l'interface.
J'aurais besoin d'une précision: père et fils gèrent-ils la partie
Tk ou le père est en fait le 'main' du script (je n'ai jamais fait de
fork) ?
2 - Il fait un fork (en thread, je n'ai jamais testé) et le fils charge Tk et crée l'interface.
Après, il faut encore gérer les communications entre le fils et le père. Côté père, c'est du classique (quoique...). Côté fils, il faut demander à Tk de surveiller un filehandle (celui qui communique avec le père) en plus de la surveillance de l'interface.
J'aurais besoin d'une précision: père et fils gèrent-ils la partie Tk ou le père est en fait le 'main' du script (je n'ai jamais fait de fork) ?
C. Tobini
Paul Gaborit
À (at) 28 Sep 2006 05:29:49 -0700, "ctobini" écrivait (wrote):
J'aurais besoin d'une précision: père et fils gèrent-ils la partie Tk ou le père est en fait le 'main' du script (je n'ai jamais fait de fork) ?
Seul le fils gère l'interface Tk. Le père ne doit même pas charger les modules Tk. Le père effectue la "vraie" tâche.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
