Hello,
voila je voudrai me lancer dans un nouveau langage de programmation pour créer des application graphique portable et simple à déployer ( pas 36000 mille truc à installe pour faire marcher le programme sur n'importe quel plateforme).
N'ayant jamais réellement touché à Python et ayant entendu beaucoup de bien sur se langage, je suis assez motivé pour m'y mettre.
Pour la bibliothèque d'interface, j'hésite entre PyQT et PyGTK.
J'ai pas beaucoup d'expérience dans ces bibliothèque.
PyQT me tente assez mais pour pouvoir bénéficier de la version libre sous windows je doit utilisé la version 4... qui ne semble ni vraiment stable et documenté ni simple à installer pour un débutant comme moi...:p
de l'autre côté, GTK semble assez bien intégré et plutôt simple, malgré qu'il ne soit pas disponible sous macOS....
que me conseilleriez vous?
merci pour la lecture de mon long dilemme :p
# Mon avis
Posté par Sten Spårvagnhög (site web personnel) . Évalué à 2.
Maintenant si c'est un pinnipède que tu dois coder, l'un n'est pas mieux loti que l'autre, pas plus que wxPython d'ailleurs.
[^] # Re: Mon avis
Posté par Sten Spårvagnhög (site web personnel) . Évalué à 2.
# Sans hésiter, je dis PyQt...
Posté par Amand Tihon (site web personnel) . Évalué à 4.
J'aime l'API et le look de Qt (avec ses styles natifs que ne j'utilise jamais, mais au cas où, ça peut servir), je n'aime pas le look, ni la licence LGPL de Gtk. Que du subjectif jusqu'à présent.
La version 4 de PyQt, comme la 3, suit de très, très près l'API de Qt. Cette API est vraiment documentée en détails sur le site de Trolltech. Et la documentation d'une bibliothèque est un critère très important à mes yeux. J'ai toujours eu beaucoup de mal à trouver de la vraie doc quand j'ai eu envie de faire du Gtk+. Ça a peut-être changé depuis.
En ce qui concerne la stabilité et le déploiement sous des plateformes non-libres, je laisserai parler d'autres que moi :)
[^] # Re: Sans hésiter, je dis PyQt...
Posté par outreal . Évalué à 1.
Ne cherche pas de la doc du côté de PyQT, regarde directement dans le site de trolltech. En effet, comme l'a dit Amand API de PyQT suit vraiment de très près l'API de Qt. Essaie de suivre un petit tuto pour commencer et tu verras qu'il est vraiment très simple d'utiliser la doc Qt, même si elle est faite pour C++.
P.S.: j'avais ceci donc mes bookmarks, je ne sais pas ce que ça vaut
http://www.cs.usfca.edu/~afedosov/qttut/
# Retour d'expérience fraîche
Posté par Sylvain Sauvage . Évalué à 3.
Je viens de réaliser un petit programme à la fois en Gtk, avec libglade, et en Qt, avec QWidgetFactory. Le principe étant, dans les deux cas, de ne pas générer de code mais de charger le fichier .glade/.ui réalisé sous Glade/Kdevdesigner (les deux sont du XML, dont aussi modifiables « à la main »). Ce fichier est modifiable indépendamment du code.
Je peux te donner quelques points positifs (+) et négatifs (-) des deux approches :
Gtk :
+ la libglade est très bien faite ;
+ Glade est assez sympa, il permet de manipuler toutes les propriétés des widgets ;
- la gestion de la mise en place (layouts) est assez casse-bonbon si on a pas décidé à priori (p.ex., si on oublie une colonne au milieu, il faut faire des couper-coller pour déplacer le contenu des colonnes à droite, quand ça fait pas planter le bouzin) ;
- Glade est multi-fenêtre à la Gimp (normal) ;
+ le MVC des GtkTreeView (et autres) : j'aime bien le MVC ;
- le MVC des GtkTreeView : ce n'est pas super pratique de jongler avec le modèle du TreeView et notre propre modèle ;
+ les icônes et les boutons prédéfinis dans Glade.
Glade s'oriente de plus en plus vers l'utilisation de la libglade (Glade-3 n'aura plus de générateurs de code intégré (mais on pourra toujours le faire)).
Qt :
+ la gestion des positions est plus pratique : on place les objets et on les groupe ensuite, on peut changer d'avis à tout moment ;
- pas de vrai MVC pour les QListView ;
+ mais il suffit d'hériter de QListViewItem pour coupler son modèle avec le QListView, donc MVC facile ;
- on ne peut pas faire du KDE avec QWidgetFactory (la classe qui construit les objets à partir du .ui) : dommage, il y a des fonctionnalités sympas dans les classes K ;
+ les connexions entre signaux (événements) et slots (callbacks) se fait graphiquement : on trace une flêche entre deux widgets ;
- une seule fenêtre/dialogue par .ui (ça limite l'utilité du point précédent).
Qt est plus orienté vers la génération de code. L'héritage y est préféré à l'utilisation.
Qt4 utilise(ra) le xml pour définir les menus et les barres à outils mais la création dynamique à partir du .ui est laissée de côté.
En fait, je n'ai pas vraiment de préférence pour l'un ou pour l'autre : libglade est super mais j'ai tendance à préférer la philosophie objet de Qt.
J'aurais peut-être un peu plus d'arguments quand je me serai vraiment attaqué à l'internationalisation de l'application.
# Multiplateforme sans installer des tas de choses
Posté par 태 (site web personnel) . Évalué à 3.
« Bien qu' » aurait été mieux que « malgré qu' ».
py-gtk est disponible sous macOS, mais ça ne rentre pas dans le cahier des charges de ne pas avoir à installer 36000 trucs. Vu qu'il faut installer gtk, donc X et un autre python (sauf ceux qui sont prêts à triffouiller la version préexistante de python à leurs risques et périls).
pyqt, je ne sais pas pour OSX, ça ne fait pas partie des paquets que me propose Darwinports.
Le mieux pour OSX, c'est d'utiliser wxwidgets puisque wxpython est installé de base. Ou bien sur Tk. Sous unix, wxwidgets marche très bien (ça fait du gtk). Sous windows, wxpython existe et ne doit pas être trop galère à installer.
# installation...
Posté par eMerzh (site web personnel) . Évalué à 1.
pour installer pyqt, il faut avoir installé SIP puis QT, puis seulement PyQT??
c un poil compliqué non?? enfin bon moi j'aimerai pouvoir lire mes applications par des newbee de chez newbee...style mes parents quoi?
[^] # Re: installation...
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 2.
Tu va pas avoir beaucoup de possibilités :
- soit tu te paye une licence WinDev_je_sais_pas_quoi (j'imagine que tes parents sont actuellement sous Windows)
- soit tu converti tes parents à Linux et tout devient simple.
Sous son air moqueur, mon commentaire cache un vrai conseil. En effet, comme Windows/MacOS et GNU/Linux n'ont jamais accordé leurs violons (et ne les acorderons surement jamais) quand à des API graphiques communes, ce sera toujours difficile de faire du multi-plateforme simple à installer.
Dans ce crénau, y'a que Java qui entre-ouvre une porte puisque :
- java fonctionne sur toutes les plateformes citées ;
- java est souvent installé sur le desktop de tout utilisateur lambda ;
- java embarque son toolkit graphique.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.