Discussion :

[Jiyuu]

Quel framework utilisez-vous pour les interfaces graphiques de vos programmes Python en 2013 ?
Quelles sont les raisons qui ont motivé ce choix ?

Bonjour,

Le développeur Python, amateur ou non, a un choix important en ce qui concerne la bibliothèque graphique lors de la conception de ses programmes.

Pour des raisons d’habitude, de plateforme, de licence, d'esthétiques ou toute autre raison son choix va alors se tourner vers un framework GUI bien précis.

Et vous ?

Avec quel framework GUI travaillez-vous actuellement ? Pour quelle(s) raison(s) ?
Seriez-vous prêt ou envisageriez-vous de changer ? Si oui, pour lequel ? Et pourquoi ?
Ou bien êtes-vous de ceux qui pensent que Python, c'est bien mais pas pour des GUI. Quels sont vos griefs ? Que manque-t-il à Python ?

Participez au débat et n'hésitez pas à argumenter votre vote en confrontant votre point de vue avec les autres membres et en donnant les raisons de votre choix, vos expériences passées, vos remarques... N'hésitez pas à discuter l'évolution depuis notre précédent sondage.

Bon vote à tous

[palnap]

On peut faire des interfaces graphiques en Python ?

[olaxius]

bonjour,
J'ai choisi wxpython pour le nombre de ses widgets et leur esthétisme .
Point noir il n'y a pas de version pour python 3 dommage .

[Jiyuu]

bonjour,
J'ai choisi wxpython pour le nombre de ses widgets et leur esthétisme .
Point noir il n'y a pas de version pour python 3 dommage .

Une bonne raison peut-être de passer à PyQt ou PySide (comment ça je ne suis pas impartial ? )

[jpver]

Bonjour,

J'utilise wxPython 2.8.12. Il y a vraiment beaucoup de sortes de widgets.
Le widget wx.grid est très souple pour représenter les données sous forme de grille.
Le module d'impression est correct (seul petit bug gênant : quand je demande 2 copies, j'en reçois 4).

Je ne connais pas PyQt / PySide. De toute manière, ça me prendrait beaucoup trop de temps pour transformer mes programmes.

Pour info, une version wxPython 2.9.5 pour Python 3.2 et 3.3 est en cours de développement (http://www.wxpython.org/Phoenix/snapshot-builds/). Elle me semble déjà fonctionnelle pour une utilisation simple. Je ne l'utilise pas car l'outil wx.grid me semble buggé (gridCellRenderer, gridCellEditor, déplacement des colonnes, ...).

[vincent.mbg]

Bonjour

J'utilise Tkinter il est simple et en natif sous python. Les petits moins, les widgets sont moins nombreux que dans les autres bibliothèques et Tkinter n'est pas super thread safe même si Tcl/tk est compilé avec l'option enable threads.

[deusyss]

Bonjour à tous,

Personnellement, j'utilise PYGTK. Bien qu'un peu brut de décoffrage, au niveau esthétique, il est relativement aisé de le prendre en main, et les widgets présents sont suffisants pour la plupart des usages. De plus, travaillant sous environnement GTK, cela semble plus naturel.

Si je désire ne pas embêter l'utilisateur avec des librairies externes, j'utilise tkinter. Mais j'avoue ne pas etre fan du style "bloc de beton"

Concernant le changement, je n'en ressent pas le besoin. Mais sinon, j'hésiterai je pense entre wx et qt, pour leur côté esthétique. J'y viendrai probablement un jour mais ce sera avant tout par curiosité. Peut être après par conviction.

[le merou]

J'ai un peu utilisé PyQt pour un projet professionnel, et couplé avec QtDesigner ça reste une bonne solution si correctement installé (j'utilise la distribution WinPython qui est relativement bien équipé).
http://code.google.com/p/winpython/

Par contre j'ai récemment découvert Kivy et sa gestion du "multi-touch" et je pense l'utiliser pour un futur projet.
http://kivy.org/

[Jiyuu]

Sans grande surprise j'ai voté pour PyQt / PySide.

Pourquoi ?
Avant tout, il faut savoir que je suis passé par Tkinter () puis wxPython avant d'arriver à PyQt / PySide. Je connais donc ces deux frameworks, même si cela fait un bail que je ne les ai plus utilisés.

Le gros avantage avec PyQt / PySide réside notamment dans le fait qu'ils sont extrêmement complets et très régulièrement mis à jour, en particulier PyQt qui suit de très prêt à la fois l'évolution de Python et celle de Qt (la dernière version de PyQt est compatible avec Python 3.3 et est basée sur Qt 5.1)

Avec ces framework il n'y a quasiment rien que l'on ne puisse faire, ce qui m'avait même pousser à me poser la question : si j'ai le choix, vaut-il mieux utiliser les outils originels de Python ou plutôt préférer ceux du framework ?

Leur utilisation est aussi très aisée et la documentation très complète. Il est en outre assez simple de trouver de l'aide avec la doc Qt ou la FAQ Qt si jamais il manque des infos en "pur" PyQt / PySide.

Et pour finir, l'esthétique est vraiment très bien faite.

Que du positif quoi

[wiztricks]

Salut,

Je ferais la même réponse qu'il y a 3 ans: il n'y a toujours pas de GUI Python qui s'impose au delà de bindings qui permettent aux programmeurs d'utiliser Tk, Qt, Wx, ... a partir de Python.

Ce qui conduit a plusieurs défauts:

• Pour les utiliser efficacement, le programmeur devra traduire une documentation et des exemples écrits pour un programmeur C, C++, TCL,... C'est bien pour la gymnastique des neurones, mais arriver a traduire sans perte n'est pas gagne.
• Les différences dans la gestion mémoire ne sont pas toujours maîtrisables (Python utilise un GC, les frameworks autre chose). Ce qui rend délicat la maintenance de telles applications (au delà du brico, proto, truc fait sur un coin de table).
• Certains frameworks sont "intrusifs": Qt par exemple apporte beaucoup de fonctionnalités que Python a déjà. Faut-il utiliser le paradigme Qt (et pourquoi programmer en Python dans ce cas) ou programmer en Python sauf pour la partie GUI?(*)
• Comme ce sont des "bindings", il est aussi complique de les utiliser en natif qu'en Python (nombre de lignes). La facilite de leur mise en œuvre avec Python est sympa pour débuter, mais pourra devenir contre-productive au delà.

Pas de soucis tant qu'on reste dans le brico, proto,... On utilise souvent dans ce cas, les fonctionnalités "basiques" , illustrées dans les tutos, et (relativement) faciles a mettre en œuvre quelque soit le framework.

Ceci dit Wx, Tk, Qt, Gtk,.... sont des frameworks de GUI de l'informatique client/serveur du siècle dernier. Plein d'applications ont ete construites avec et il est bon de savoir comment ça fonctionne pour se depatouiller avec.

Les IHM d'aujourd'hui sont plutôt HTML5, JavaScript, CSS et Kivy (déjà cite) ou panda3d sont un peu moins "has been".

- W

[Jiyuu]

Les IHM d'aujourd'hui sont plutôt HTML5, JavaScript, CSS et Kivy (déjà cite) ou panda3d sont un peu moins "has been".

Et QML disponible avec PyQt5 .

[wiztricks]

Et QML disponible avec PyQt5 .

QML est une interface déclarative.
Si on veut faire du HTML5, ça passe par du Webkit et GoogleV8 qui sont intégrés a Qt mais aussi disponibles "ailleurs".
Ca permet de rafraîchir le framework. Et c'est une bonne chose pour prolonger la vie des applications existantes.
Mais les nouvelles applications ont une structure différente.


- W

[tyrtamos]

Bonjour,

Oui, bon. Quand on voit les entreprises qui travaillent encore avec Windows XP, on se dit que les outils du siècle dernier ont encore de belles années devant eux...

En ce qui me concerne, j'utilise PyQt4 depuis 4 ans.

J'ai commencé avec tkinter, et je ne le regrette pas. Et puis, il me fallait trouver une bibliothèque graphique plus musclée pour un projet important. En particulier, il me fallait un logiciel de dessin de fenêtre pour créer des fenêtres complexes pour la saisie, et une possibilité de consulter et modifier une base de données relationnelle avec une grille type Excel. Tout cela en multiplateforme Windows-Linux-MacOSX.

J'ai regardé wxPython, PyGtk et PyQt4. J'ai éliminé wxPython parce qu'à ce moment-là, il n'y avait aucun projet pour passer à Python 3. Et entre PyGtk et PyQt4, j'ai choisi PyQt4 parce que le logiciel de dessin de fenêtre QtDesigner me plaisait beaucoup.

Je n'ai pas eu à regretter mon choix: avec PyQt4, on peut faire vraiment tout ce qu'on veut, et plus encore: on découvre en permanence des possibilités qu'on ne connaissait pas.

Avec PyQt4, j'ai fait des choses comme:

- saisie de données avec fenêtres complexes
- consultation/modification de bases de données relationnelles avec une grille. Possibilité de tri, filtrage, recherche, y compris recherche avec jokers, expressions régulières ou mot similaire. On peut afficher en interactif n'importe quel résultat de requête SQL de type select sous forme d'une grille, avec possibilité d'enregistrement en csv pour transmission à un tableur (on peut aussi transférer des données par copier-coller ou par glisser-déposer).
- création de pdf
- intégration d'un navigateur web. Je l'utilise pour afficher les manuels de mes logiciels que j'écris en html, mais on peut aussi naviguer sur le web (y compris avec javascript, flash, etc...)
- intégration d'un éditeur de texte
- création et lecture de code-barre.
- échange de données en réseau local hétérogène (surtout Windows-Linux)
- traitement multimedia: manipulation d'images et émission de fichiers audio
- création de nouveaux widgets avec intégration dans QtDesigner
- sauvegarde et restauration des données en ftp (avec barre de progression) sous forme de fichier zip
- navigation web
- émission/réception d'emails, en texte simple ou en html, avec ou sans pièces jointes
- conversion en programme "standalone" avec cx_freeze (.exe sous Windows: avec un installeur comme innosetup, l'utilisateur ne sait même pas que c'est du Python).
- etc...

Avec ça, j'ai fait un logiciel pour un concours international de photos pour mon photo-club: il fait maintenant plus de 25000 lignes. Je l'utilise depuis 3 ans et il fonctionne parfaitement.

Avec PyQt4, j'ai fait d'autres logiciels comme un programme de recherche de mots dans les fichiers d'une arborescence ou un programme d'émission d'emails en masse (plusieurs centaines) avec ou sans pièces jointes, en texte simple ou en html, pour les mailing de mon photo-club (logiciel que je ne diffuse pas, parce qu'on peut faire du spam avec...).

Ayant découvert (grâce à ce forum!) qu'on pouvait mettre un logiciel en "tray" (à droite dans la barre des tâches), j'ai créé une fenêtre PyQt4 qui encapsule l'interpréteur Python comme le fait idle avec tkinter, et qui charge plusieurs modules de calcul perso. A l'allumage de mon PC, j'ai une icône qui vient dans la zone de notification. Quand je clique dessus, la fenêtre PyQt4-Python s'affiche, et je peux faire tous les calculs que je veux (y compris une simulation de crédit bancaire par exemple). Je peux aussi appeler un éditeur de texte pour écrire une note de type "postit", ou pour me rappeler ce que j'ai écris la dernière fois. Etc... Et quand je ferme cette fenêtre, en fait elle est cachée et se réaffiche à l'identique la fois suivante: c'est vraiment très pratique.

J'ai plein d'autres projets. Par exemple, j'aimerais faire un processeur d'idée avec un affichage arborescent (QTreeWidget). Je pense aussi à un tableur (QTableWidget) qui fonctionnerait avec des scripts Python, ainsi qu'à un logiciel de sauvegarde incrémentielle. Etc...

Ce que je regrette? Que la doc de PyQt4 soit en C++ et en anglais. Avec une bibliothèque aussi complète et aussi complexe, on travaille en permanence avec la doc à l'écran.

En fait, il est surtout dommage que les dirigeants de Python n'aient pas choisi d'intégrer une bibliothèque graphique puissante comme PyQt4 (ou PyGtk!) comme module "normal" de Python plutôt que tkinter qui nécessite un "autre" interpréteur (tcl/tk): ça fait un peu bricolage. Il est aussi dommage qu'un logiciel comme cx_freeze ne soit pas intégré aussi. Avec en plus un outil de développement de type "RAD" comme pour Delphi, cela donnerait un sacré coup d'accélérateur à Python, et lui ferait perdre définitivement son image de "simple langage de script".

A part ça, j'aimerais aussi, en plus et pas à la place, programmer en Python pour les machines avec écran tactile (PC, tablettes, smartphones), avec fonction "multi-touch". Je creuse actuellement la solution "kivy" pour voir.

[Gabriel92]

Bonjour à tous, j'utilise WxPython 2.9.3 parce que l'interface graphique, sur un mac en tout cas, c'est nettement plus joli que tkinter (presque pur Mac). Il y a quelques bugs encore mais globalement cela fonctionne nickel pour moi (avec python 2.7.3). Je n'ai pas essayé les autres gui pour des raisons de temps (apprendre une interface est assez long et fastidieux au début).

[wiztricks]

Salut Tyrtamos,

Oui, bon. Quand on voit les entreprises qui travaillent encore avec Windows XP, on se dit que les outils du siècle dernier ont encore de belles années devant eux...

Programmer, c'est "construire" de nouveaux outils ou faire évoluer des "outils" existants. Il est rare de changer de GUI ou de SGBD pour une évolution et encore plus rare de changer de langage de programmation. C'est un peu moins contraint pour les nouvelles applications. Un des intérêt de Python est de permettre d'explorer de nouveaux paradigmes i.e. la construction de nouveaux outils.

Avec ça, j'ai fait un logiciel pour un concours international de photos pour mon photo-club: il fait maintenant plus de 25000 lignes. Je l'utilise depuis 3 ans et il fonctionne parfaitement.

Python et Qt sont "scalables", pas de soucis.
Mettre 25000 lignes de codes en production/maintenance d'un tel mix. n'est pas facile a vendre (en entreprise).
Cherchez un programmeur Qt, il devra connaître Qt et le développement C++. Connaître PyQt et Python sera un "plus" mais insuffisant pour le job.

Si on sort du cadre professionnel, on ne parle plus d'applications mais de "brico", "proto",... et de ses passions. Elles sont respectables mais difficile de généraliser, ...

Ce que je regrette? Que la doc de PyQt4 soit en C++ et en anglais. Avec une bibliothèque aussi complète et aussi complexe, on travaille en permanence avec la doc à l'écran.

C'est un des défauts que j'ai mentionne.
Revoyez la discussion. Faire marcher un truc est une chose, le construire proprement en est une autre.

En fait, il est surtout dommage que les dirigeants de Python n'aient pas choisi d'intégrer une bibliothèque graphique puissante comme PyQt4 (ou PyGtk!) comme module "normal" de Python plutôt que tkinter qui nécessite un "autre" interpréteur (tcl/tk): ça fait un peu bricolage.

Toutes les fonctionnalités intégrées a la "Python Standard Library" doivent répondre a des contraintes de compatibilité ascendante qui rendent difficiles leurs évolutions.

Tkinter est la depuis longtemps, imho, il faudrait pouvoir s'en défaire (installe optionnellement) plutôt que d'essayer de le remplacer (ajouter un autre truc dans la PSL).
C'est un peu comme pour sqlite, 'battery-included', c'est bien... mais c'est aussi un "soft" installable et utilisable en mode "console". Ce qui vient avec Python sera toujours décale et cause de "soucis".

Avec en plus un outil de développement de type "RAD" comme pour Delphi, cela donnerait un sacré coup d'accélérateur à Python, et lui ferait perdre définitivement son image de "simple langage de script".

"Python" est a la fois un langage de programmation mais vient avec nombre de fonctionnalités prêtes a l'emploi, la PSL qui en fait aussi une sorte de "framework", boite a outils bien pratique.

Qt est aussi un "framework" mais comme on peut l'utiliser depuis Python, C++, Java,... Il y a moins de "confusion" entre "langage de programmation" et "framework".

Si vous voulez construire une boite a outils avec les fonctionnalités DELPHI on pourrait commencer par y ajouter SQLAlchemy, Camelot,...

La plupart des composants existent en open-source.
Et vous avez des éditeurs comme ActiveState ou autres (Embarcadero) qui proposent des solutions qui intègrent composants Open Source et des composants propriétaires modulo finance.

Il faut bien rémunérer le travail de sélection, intégration, documentation, et les coûts de structure cote non-régression, montée de version, support,...
D'ailleurs DELPHI n'est ni gratuit, ni open source et encore moins un langage de programmation.

- W

[tyrtamos]

Bonjour wiztricks,

Si on sort du cadre professionnel, on ne parle plus d'applications mais de "brico", "proto",... et de ses passions. Elles sont respectables mais difficile de généraliser, ...

Vous êtes trop binaire: on vend, et c'est du professionnel, ou on ne vend pas et c'est du bricolage. Dans le domaine associatif, quand on fait un logiciel pour un concours international, il DOIT remplir ses fonctions sans bug. Ce n'est pas parce qu'on ne le vend pas qu'il ne doit pas être construit selon les règles de l'art, et avec tous les contrôles nécessaires (j'ai les qualifications pour ça). Et c'est le cas! Par ailleurs, dans le passé, j'ai déjà vendu des programmes (en Pascal), et ça s'est très bien passé. En résumé, ce n'est pas parce que je prends du plaisir à coder que je ne code pas sérieusement...

Revoyez la discussion. Faire marcher un truc est une chose, le construire proprement en est une autre.

Je n'ai pas vu le rapport avec ma remarque (doc C++ et anglais)

Toutes les fonctionnalités intégrées a la "Python Standard Library" doivent répondre a des contraintes de compatibilité ascendante qui rendent difficiles leurs évolutions.

Et oui, sauf pour Python 3 qui a un peu "cassé" cette compatibilité ascendante: on aurait pu en profiter, mais on ne l'a pas fait: c'est bien dommage.

D'ailleurs DELPHI n'est ni gratuit, ni open source et encore moins un langage de programmation.

Ça, pour ne pas être gratuit, il n'est pas gratuit: j'ai reçu une proposition de mise à jour pour ... 2000€. Waou.

Borland avait utilisé le nom de Delphi parce qu'il avait modifié assez profondément le Pascal standard (POO, graphique, etc...). Delphi représente donc en même temps ce Pascal modifié et son outil de développement "RAD" (=avec le dessin interactif des fenêtres).

Il reste que Lazarus + Freepascal (http://www.lazarus.freepascal.org/) s'en approche assez bien. De plus, il existe aussi sous Linux et MacOSX, contrairement à Delphi. Enfin, il est gratuit: c'est donc possible!!! Pourquoi pas un Python à la sauce Lazarus qui intègre PyQt et QtDesigner?

[Jiyuu]

Python et Qt sont "scalables", pas de soucis.
Mettre 25000 lignes de codes en production/maintenance d'un tel mix. n'est pas facile a vendre (en entreprise)

J'aimerai juste revenir sur cette remarque pour laquelle je suis tout à fait d'accord... sauf qu'avec PyQt (ou PySide) on a la possibilité de TOUT faire.

Une installation PyQt fonctionnelle permet de faire des choses simples comme la création d'une petite interface graphique à des choses plus complexe comme travailler avec de l'XML, imprimer des PDF, manipuler des fichiers audio, vidéo ou photo; tracer des courbes ... sans aucun rajout de bibliothèque.

En fait, si un jour Riverbank (PyQt) ou Digia (PySide) venait à avoir l'idée "d'imbriquer" la bonne version de Python dans leur exe d'installation je suis sûr que le développeur n'aurait qu'un seul programme à installer pour coder ses projets..., mais bon là il faut en installer 2 : Python et le binding voulu.

Pour revenir à ta remarque, oui mixer deux langages dans 25 000 lignes c'est dangeureux, sauf que là on pourrait en fait considérer ceci comme un seul et unique langage.
À titre de comparaison (même si l'utilisation originelle n'est pas censée être la même), on est bien loin de PHP+HTML+JS... là oui merci la maintenance.

[wiztricks]

Salut Tyrtamos,

Vous êtes trop binaire: on vend, et c'est du professionnel, ou on ne vend pas et c'est du bricolage.

Pas du tout!
Il y a des différences entre un soft ecrit sur un coin de table et une application open source ou propriétaire dont architecture, code et livrables devront être présentés, discutés, documentes, développes et maintenus par d'autres que soi.

Dans le domaine associatif, quand on fait un logiciel pour un concours international, il DOIT remplir ses fonctions sans bug. Ce n'est pas parce qu'on ne le vend pas qu'il ne doit pas être construit selon les règles de l'art, et avec tous les contrôles nécessaires (j'ai les qualifications pour ça).

Tout logiciel mérite d’être "bien construit". Les méthodes existent, les moyens ne sont pas toujours a la hauteur.
Parmi ces moyens, faire "contrôler", et "faire revoir" son code par d'autres est (insuffisant mais) nécessaire pour garantir un minimum de qualité.
Cela ne veut pas dire que votre code n'est pas bien construit juste que vous confondez "confiance" et "qualifications" avec "contrôle" et qualité"...

- W

[wiztricks]

Re:

Et oui, sauf pour Python 3 qui a un peu "cassé" cette compatibilité ascendante: on aurait pu en profiter, mais on ne l'a pas fait: c'est bien dommage.

C'est parce qu'on casse qu'on doit bumper la version
Si ce n'avait pas été le cas, on aurait fait un Python 2.8.
- W

[tyrtamos]

@wiztricks

J'arrête de discuter ici. J'ai donné mon avis, et il n'a pas changé. Le reste ne m'intéresse pas.