 |
| sortir d'une fonction d'une lib externe appellée depuis view | |
| bob le bricoleur | 11-Jun-2014/23:25:43+2:00 |
| Bonsoir, Je suis en train de "coder" une petite appli qui à les 2 fonctions suivantes : - afficher une suite de photos avec des effets utilisant draw - jouer une suite de mp3 en même temp j'utilise la lib libwmp3 pour lire les mp3 je commence à jouer mon premier mp3 avant ma fonction view dans ma fonction view, j'utilise feel/engage/time pour "updater" mes images et mes musiques. Problème : quand je passe au second mp3 de ma liste, la musique démarre mais view perd la main car ma function qui lit le mp3 prend le dessus et à la fin le script s'arrete sans passer au mp3 suivant. Question : comment sortir de la fonction qui lit le mp3 et rendre la main à view ? et surtout pourquoi lorsqu'on utilise la même fonction en dehors de view, cela fonctionne ? J'ai essayé pas mal de chose sans succès (return, exit... dans la fonction play-mp3) J'ai aussi regardé le script de françois Jouen sur le "multithreading" mais mon piètre niveau ne permet pas fe faire le lien avec mon problème (sachant que sa demo ne concerne que view). Une solution simple à mettre en oeuvre ? Olivier | |
| shadwolf | 12-Jun-2014/0:59:33+2:00 |
| bob c est le probleme des langages sans concepte de thread. il ya quelques decades de ca LDCI avait proposer une simulatiion du procede de thread mais je ne sais pas si ca peux marcher avec r3 ou avec un lib externe, bref si ca peut t aider jette un oeil la dessus ! http://www.rebol.org/view-script.r?script=threaddemo.r&sid=cjkwk53lv sinon l autre idee c est de passer par 2 script rebol ... tu sors de ton script rebol/view la fonction lecture en la plaquant dans un mini serveur et ton GUI sert de client de se server. ton client lance un nouveau mini serveur avec le nouveau fichier puis lui balance des commandes qui vont bien "play", "pause", "stop", etc enfin tu peux essayer le fameux traitement asynchrone qui plait tant a Carl mais la j ai pas d idees sur l implementation pratique de la chose. | |
| ldci | 12-Jun-2014/21:56:50+2:00 |
| Pas évident tout ça avec Rebol. Dans threaddemo, c'était une illustration du principe général d'un temps partagé entre plusieurs processus. L'idée est de basculer rapidement d'une tache à l'autre pour donner l'impression du multithreading. Malheureusement avec Rebol on est limité. C'est pour pallier ce type de problème que j'avais choisi de développer le bus logiciel Rencontre que j'ai présenté à la DevCon en 2007. Rencontre est conçu comme un modèle de communications entre agents dynamiques. Son principe est très simple : les agents se connectent sur le bus logiciel, envoient des messages et ont la possibilité de quitter le bus sans bloquer l’activité des autres agents. Une autre caractéristique de Rencontre est la simplicité du protocole d’échange des données que nous avons adopté. Les agents, quelque soit le système d’exploitation ou le langage de programmation, doivent être capables d’envoyer et de recevoir de simples messages texte (une chaîne de caractères) qui ne contient que deux informations : le nom de l’agent émetteur et le contenu du message. Les messages sont organisés de la façon suivante : Application Name : Message. Enfin chaque agent est responsable du traitement des données envoyées par les autres agents. Soit les données sont utiles pour lui et dans ce cas, l’agent les traite. Soit les données sont inutiles et dans ce cas, le message est ignoré. Dans ton cas, cela pourrait marcher sans problème avec un agent pour les images et un agent pour la musique. Je vais retrouver le code original et le mettre sur GitHub. Sinon, tu peux aussi regarder le code de Nenad async-call qui permet des appels non bloquants à l'intérieure d'une même boucle view Bon courage | |
| ldci | 16-Jun-2014/17:51:49+2:00 |
| Comme promis https://github.com/ldci/Rencontre-Rebol Amitiés à tous | |
| bob le bricoleur | 16-Jun-2014/19:20:13+2:00 |
| @ ldci Merci François. je m'en servirai pour la prochaine version. J'ai contourné le problème de façon peut élégante mais très simple, en écrivant une variable dans un fichier qui est lu et écrit par les 2 scripts. simple et efficace mais pas très rebolien. Par contre j'ai un autre problème plus ennuyeux et plus immédiat avec l'affichage ou plus directement la fonction focus qui me fait une belle barre en plein milieu de la face affichée ! une idée myscreen: layout [ size screensize ; full screen window backdrop black ; backdrop color b: box 800x600 effect [draw [] ] rate 0 feel [ engage: func [face action event] [ if action = 'key [ if event/key = #"q" [print "writefile" writefile unview/all quit] if event/key = #"p" [print "pause" ] ] if action = 'time [update-image] ] ] do [b/offset: screensize / 2 - (b/size / 2)] do [focus b] ]0x0; no offset window view/options center-face myscreen [no-title no-border] j'ai essayé de contourné le focus de la face par un insert-event-func global mais sans succès. Olivier | |
| DideC | 16-Jun-2014/23:50:50+2:00 |
C'est le focus qui pause problème. Evitons le  Il suffit de gérer les actions clavier avec des faces 'key : screensize: 1024x768 update-image: does [print "update"] myscreen: layout [ size screensize ; full screen window backdrop black ; backdrop color b: box 800x600 effect [draw [] ] rate 0 feel [ engage: func [face action event] [ if action = 'time [update-image] ] ] do [b/offset: screensize / 2 - (b/size / 2)] key #"q" [quit] key #"p" [print "pause"] ] view/options center-face myscreen [no-title no-border] | |
| bob le bricoleur | 17-Jun-2014/15:13:49+2:00 |
| @ DideC Merci (j'ai utilisé cette solution hier soir à force de "chercher comme un grand"), et c'est bien plus simple et efficace qu'une fonction insert-event. D'après les docs Rebol, le focus n'est normalement destiné qu'au faces de type field et area d'ou l'artefact graphique. Merci encore olivier | |
|
Login required to Post. | |