J'ai un petit soucis gtk mais je ne sais pas si ça viens de moi ou pas.
Je suis en train de developper un truc en Ruby/Gtk (mais la question est général et je vais faire en sorte d'utiliser les notations C) et j'ai besoin de faire une sorte de drag'n drop dans un GnomeCanvas. J'utilise une fonction on_bp de rappel qui se déclanche sur un "button_press_event" qui va ensuite définir une fonction de rappel on_mn pour un "motion_notify_event" qui est déconnecter avec un signal_handler_disonnect lors d'un "button_release_event" (fonction on_br).
Pour accélérer un peu le bouzin (j'ai un peu de calcul a faire après cahque mouvement de la souris) j'utilise une boucle du style
while(gtk_event_pending()) {gtk_main_iteration();}
dans ma fonction on_mn
Bon jusque là pas de problème. Sauf que (ben oui, sinon je ne poserait pas ma question) quand je bouge trop vite ma souris (en faite le pad de mon ibook (je ne sais pas si ça peut jouer, j'ai pas de souris)) j'ai des signaux "button_press_event" qui doivent se déclancher intempestivement puisque la fonction on_bp est appelée à partir de la boucle while dans on_mn. Résultat une pile d'appelle qui déborde.
Si j'enlève la boucle while forcément c'est bon, mais c'est trop lon à calculer. Mais de toute façon il ne devrait pas y avoir de "button_press_event" dans la boucle puisque je ne lâche pas mon pad. Pourquoi diable on_bp est elle appelée?
Pour résoudre ce problème j'ai essayé de déconnecter les "button_press_event" de on_bp en utilisant des signal_handler_block ou des signal_handler_disconnet dès l'entré dans on_bp (je les reconnecte / débloque dans on_br). Mais ça ne marche pas. J'ai toujours des appels à on_bp depuis la boucle while de on_mn. Est ce normal que cela ne marche pas?
Pour finir une dernière question: Comment est ce que je pourrais faire pour remplacer ma boucle while par une vidange complète (ou du moins ce certains types de signaux (genre les "button_press_event")) de la file des signaux sans que les fonctions de rappel soient appelé?
Est ce que vous avez d'autres solutions à me proposer?
J'ai pas l'impression que le D'nD soit la solution à mon problème. Me trompe-je?
Est ce que vous avez compris mon problème ou c'était vraiment pas claire?
D'oh!
# oublie gtk_main_iteration
Posté par HollowMan . Évalué à 2.
Je pense que l'une des solution est de disposer d'un flag qui te permet de savoir si tu es déjà en train de traiter le drag.
Si c'est le cas soit:
1. tu sauvegardes la dernière position, tu termines le idle sur l'ancienne position, puis tu passes à la nouvelle position.
2. tu abandonnes le traitement de l'ancienne position et tu passes à la dernière position
L'avantage de la solution 1, est que tu es sûr d'afficher des choses, au prix d'une certaine latence.
En ce qui concerne le cas 2, l'affichage du drag se fera avec moins de latence, mais l'affichage risque d'être inhiber lors du déplacement si les temps de repos ne sont pas assez longs.
[^] # Re: oublie gtk_main_iteration
Posté par HSimpson . Évalué à 1.
J'ai découvert ce matin le MOTION_HINT_MASK qui évite de saturer la queue des signaux avec des motion_notify_event. Pour générer un nouveau signal on appel alors un gtk_window_get_pointer.
J'ai aussi utiliser un test du genre (event->state & GDK_BUTTON_MASK) dans ma fonction on_mn. Je capte tout les mouvements de la souris (même hors drag) mais je sort direct si je ne suis pas en drag. Du coup, avec ça je n'est plus besoin de faire tout mon mic-mac de branchement/débranchement de on_mn.
Je me suis inspirer du tuto de GtkFr (http://www.gtk-fr.org/wakka.php?wiki=CreerSonProprePaint ) que je connaissais pas avant.
Est ce que quelqu'un sait quand même pourquoi j'avais des "button_press_event" et pourquoi mon mic-mac ne marchait pas.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.