Ha en fait tu confonds Qt et les bindings Qt pour Python, c'est ça ?
Ha ?
Non... Je parle de PyQT depuis le départ. Je n'ai jamais fait de C++Qt et je ne veut pas en faire (pour pleins de raisons, la première étant que je trouve stupide de s’embêter avec du C++ pour programmer, à mon humble avis, 99.9% des usages actuels du C++ sont non justifiés). La dépêche parlait de python, et ce fil de commentaire de PyQT/PyGTK, donc il n'y a pas trop de problème à ce que je parle de PyQT.
Je vois pas le problème dont tu parles avec les évènements pour le déplacement de la souris. Moi je parle de la sélection de texte et de ses intéractions foireuses avec le buffer souris sur Gtk : https://linuxfr.org//~mildred/29854.html
Ok. Personnellement cela ne m'a jamais posé problème, mais je me sert très peu de la souris. Ce qui me saoul ici avec Gtk c'est que lorsque l'on s’intéresse aux event souris, soit l'on en reçoit une quantité énorme non traitable en temps utile si le traitement prend un peu de temps (genre 100/s) si la souris bouge vite. Soit l'on peut activer le *buffer* (MOTION_HINT_NOTIFY) qui normalement se contente d'envoyer un seul event jusqu'à ce que tu lui dise qu'il peut en envoyer de nouveau, mais pourtant il continue à en envoyer plein.
Tout comme Gtk impose l'utilisation de la glib. Je vois pas le problème.
Avec pygtk je n'ai JAMAIS utilisé directement la glib. Je n'ai jamais utilisé la variante de string de la GLib, ni les structures de données de la Glib. A l'époque ou j'avais fais un peu de PyQT, je devais instancier des QString pour faire correctement fonctionner l'unicode et il m'arrivait de devoir charger des QList ou autre.
Le binding pygtk est vraiment intégré de façon transparente à python. Apparemment c'est mieux pour le binding pyQT pour python3. En résumé je veux bien faire du QtGui, mais pas du QtList, QTString, QTFile, QtTortue.
Bref, quand python3 sera utilisable pour moi en production (mon attente principale étant numpy) et si quelqu'un me trouve comment faire pour connecter un signal de qt designer sur un slot de mon code, je redonnerais à pyqt sa chance. En attendant, pygtk est bien plus au dessus pour mon besoin à moins en confort de programmation.
[^] # Re: PyGtk/Python3
Posté par Guillaum (site web personnel) . En réponse à la dépêche Python 2.7. Évalué à 3.
Ha ?
Non... Je parle de PyQT depuis le départ. Je n'ai jamais fait de C++Qt et je ne veut pas en faire (pour pleins de raisons, la première étant que je trouve stupide de s’embêter avec du C++ pour programmer, à mon humble avis, 99.9% des usages actuels du C++ sont non justifiés). La dépêche parlait de python, et ce fil de commentaire de PyQT/PyGTK, donc il n'y a pas trop de problème à ce que je parle de PyQT.
Je vois pas le problème dont tu parles avec les évènements pour le déplacement de la souris. Moi je parle de la sélection de texte et de ses intéractions foireuses avec le buffer souris sur Gtk : https://linuxfr.org//~mildred/29854.html
Ok. Personnellement cela ne m'a jamais posé problème, mais je me sert très peu de la souris. Ce qui me saoul ici avec Gtk c'est que lorsque l'on s’intéresse aux event souris, soit l'on en reçoit une quantité énorme non traitable en temps utile si le traitement prend un peu de temps (genre 100/s) si la souris bouge vite. Soit l'on peut activer le *buffer* (MOTION_HINT_NOTIFY) qui normalement se contente d'envoyer un seul event jusqu'à ce que tu lui dise qu'il peut en envoyer de nouveau, mais pourtant il continue à en envoyer plein.
Tout comme Gtk impose l'utilisation de la glib. Je vois pas le problème.
Avec pygtk je n'ai JAMAIS utilisé directement la glib. Je n'ai jamais utilisé la variante de string de la GLib, ni les structures de données de la Glib. A l'époque ou j'avais fais un peu de PyQT, je devais instancier des QString pour faire correctement fonctionner l'unicode et il m'arrivait de devoir charger des QList ou autre.
Le binding pygtk est vraiment intégré de façon transparente à python. Apparemment c'est mieux pour le binding pyQT pour python3. En résumé je veux bien faire du QtGui, mais pas du QtList, QTString, QTFile, QtTortue.
Bref, quand python3 sera utilisable pour moi en production (mon attente principale étant numpy) et si quelqu'un me trouve comment faire pour connecter un signal de qt designer sur un slot de mon code, je redonnerais à pyqt sa chance. En attendant, pygtk est bien plus au dessus pour mon besoin à moins en confort de programmation.