Bonjour tout le monde.

Je me casse la tête depuis plusieurs jours sur le choix d'une bibliothèque graphique pour mon projet. Je code en Python 3.2.3.

Mon projet comportera de nombreux champs de caractères puisqu'il doit permettre à plusieurs dizaines de personnes de discuter ensemble tout en jouant à des jeux tels que les échecs, ou les dames.

Par conséquent, je m'étais intialement porté sur pygame... mais impossible de faire des champs de texte, des barres déroulantes, etc. Je ne suis pas vraiment motivé pour tout coder moi-même

Est-ce qu'une bibliothèque comme wxPython est suffisante pour mes besoins ? Je dois pouvoir faire des jeux de carte, d'échec ou de dames avec un bon rendu.

Est-ce que wxpython est portable sur linux ?

Merci beaucoup !

PS : je sais qu'il est possible d'afficher des images dans wxPython mais en pratique, est-ce adapté à mon projet ?

PS2 : Heu, apparemment wxpython n'est pas compatible avec Python 3.2.3... d'autres idées ?

--> Recherche Google "bibliothèques graphiques python" - 1er résultat

Bonjour,

Apprenez les bases du langage, vous verrez que le choix s'imposera de lui même...

Pour les bibliothèques graphiques, PyQt/PySide est probablement le plus recommandé.

Après, pour ce qui est de faire des jeux de cartes, c'est un peu particulier, mais c'est très certainement faisable de plein façons différentes, quitte à utiliser Qt avec un autre backend graphique utilisant OpenGL, par exemple (Qt sait gérer des contextes OpenGL).

Bonjour,

TouzaxA : je ne cherche pas une liste de toutes les bibliothèques existantes pour Python, je suis assez grand pour effectuer une recherche sur Google tout seul.

fred1599 : apparemment pas puisque je connais les bases du langage et j'hésite toujours sur la bonne bibliothèque graphique à utiliser.

nohar : parfait. PyQt a l'air intéressant. Ce lien me pousse dans mon choix :

http://stackoverflow.com/questions/453 [...] hon-card-game

Il est apparemment possible de créer des champs de texte et des menus facilement, tout en concevant des jeux. Je reviendrais mettre le sujet en "résolu" si je valide ce choix.

Merci beaucoup pour vos réponses

PS : j'ai un peu de mal à comprendre pourquoi certaines bibliothèques comme Pygame (SDL) ne permettent pas de créer des champs de texte tandis que PyQt le permet. On dirait qu'il y a des bibliothèques pour les applications, et d'autres pour les jeux

Citation

apparemment pas puisque je connais les bases du langage et j'hésite toujours sur la bonne bibliothèque graphique à utiliser

Avec soit disant les bases, la proposition de nohar aurait été une évidence (nous n'avons certainement pas la même notion de bases).

Citation

Il est apparemment possible de créer des champs de texte et des menus facilement, tout en concevant des jeux

facilement? on verra bien
PyQt est très complet mais tout aussi complexe.

Citation

PS : j'ai un peu de mal à comprendre pourquoi certaines bibliothèques comme Pygame (SDL) ne permettent pas de créer des champs de texte tandis que PyQt le permet. On dirait qu'il y a des bibliothèques pour les applications, et d'autres pour les jeux

Quel est le rapport entre un champs texte, et un jeu ?
Dans votre question se trouve la réponse.

Une partie d'échec doit permettre de jouer tout en discutant sur un tchat. Or, ce n'est pas exotique, ça se retrouve dans de nombreux programmes... c'est pourquoi je suis étonné qu'il y ait deux types de bibliothèque graphique.

L'idée que vous vous faites des bases intéresse certainement beaucoup de personnes, ouvrez donc un topic et exprimez vos idées.

Les bases? Par analogie je dirais que c'est la base d'une pyramide, c'est la surface la plus grande.
Si sur cette base on y trouve des failles, on risque l'éboulement de la pyramide.

Je considère que sur tout une vie de travail dans la programmation, c'est la partie la plus longue à maîtriser.

Ça doit faire 7/8 ans que je fais du python, et je ne considère pas avoir les bases suffisantes et pourtant j'applique du python tous les jours...

Citation : Ephysio

Une partie d'échec doit permettre de jouer tout en discutant sur un tchat. Or, ce n'est pas exotique, ça se retrouve dans de nombreux programmes... c'est pourquoi je suis étonné qu'il y ait deux types de bibliothèque graphique.

Le tchat c'est du réseau et non du jeu, cela reste une particularité réservé à une bibliothèque graphique et fonctionne séparément du jeu en lui même.

Citation : Ephysio

PS : j'ai un peu de mal à comprendre pourquoi certaines bibliothèques comme Pygame (SDL) ne permettent pas de créer des champs de texte tandis que PyQt le permet. On dirait qu'il y a des bibliothèques pour les applications, et d'autres pour les jeux

Parce que ce sont deux approches différentes qui ne se situent pas au même niveau d'abstraction.
Les bibliothèques comme Qt ou GTK présupposent que le soft va être exécuté dans un environnement de bureau classique, avec des fenêtres comme on les connait bien.

Les autres bibliothèques (SDL, Allegro et OpenGL en particulier), ne font pas cette supposition. SDL présuppose simplement l'existence d'un framebuffer, OpenGL celle d'une carte graphique (possiblement émulée de façon logicielle) respectant la norme OpenGL et d'une surface pour faire les rendus (classiquement, un écran, mais ça peut être une surface contenue dans une fenêtre Qt, par exemple).

Dans ce contexte, les bibliothèques de GUI fenêtrées utilisent les capacités du backend (sous Linux, par exemple, c'est classiquement un serveur X + un environnement style Gnome ou KDE), et vont y faire appel pour l'affichage de texte ou de widgets, alors que les autres gèrent leur surface intégralement. Dans les unes, on est donc limité par le backend en termes de possibilités (on ne peut pas dessiner directement à l'écran, du moins pas en payant un sérieux overhead en performances), mais certaines tâches courantes se font de façon transparente, alors que dans les autres, on n'a aucune limite, mais aucune ressource pour nous faciliter la tâche non plus (à part en créant une petite surcouche spécialisée pour la gestion du texte, par exemple). Ce sont deux approches inverses et complémentaires.