Comparatif PyQt, Tkinter, WxPython, PyGtk
Méta-MCI (MVP)
Malgré qu'il soit en anglais, cet article pourrait intéresser des
pythonneux :
http://ojs.pythonpapers.org/index.php/tpp/article/view/61/57
--
@-salutations
--
Michel Claveau
Encolpe Degoute
> Bonjour !
>
> Malgré qu'il soit en anglais, cet article pourrait intéresser des
> pythonneux :
> http://ojs.pythonpapers.org/index.php/tpp/article/view/61/57
Très intéressant, merci
--
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales
Méta-MCI (MVP)
Content que ce lien ait plu à au moins une personne.
Cela encourage à continuer...
@-salutations
--
Michel Claveau
Eric Brunel
<enleverl...@XmclaveauX.com> wrote:
> Bonjour !
>
> Malgré qu'il soit en anglais, cet article pourrait intéresser des
> pythonneux :
> http://ojs.pythonpapers.org/index.php/tpp/article/view/61/57
Ce document semble bien vieux... Typiquement, il n'a pas l'air d'intégrer
les nouveautés de tcl/tk 8.5, ce qui est d'autant plus étonnant que
l'auteur est justement celui qui a écrit les wrappers Tkinter pour les
nouveaux widgets... De plus, l'URL donnée dans le document pour les codes
source des exemples ne fonctionne plus.
Bref, je ne sais pas pour les autres toolkits, mais pour Tkinter, le
document n'est pas très significatif. Dommage...
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
Méta-MCI (MVP)
Pourtant, il vient du volume 3 (page 26 à 37) de 2008, de "The Python
Paper".
Voir :
http://ojs.pythonpapers.org/index.php/tpp/issue/view/8
@+
--
MCI
Eric Brunel
Etonnant en effet... J'ai jeté un oeil au code pour Tkinter, et c'est
encore plus étrange: des choses inutiles, utilisation de conventions
obsolètes... Ca ressemble beaucoup à un vieux code repris sans adaptation.
Pour ceux que ça intéresserait, le look sur Tkinter aujourd'hui après
adaptation du code pour utiliser les nouveaux widgets, c'est ça:
http://img105.imageshack.us/img105/1144/screenshotvz4.png
(en espérant que l'image reste...)
C'est quand même un peu moins mal que ce qu'il y a dans le document...
yves...@gmail.com
Tkinter aurait-il une nouvelle version ? Ca m'intéresse parce que
j'aime bien utiliser Tkinter pour sa simplicité.
A moins que ce ne soit une question de modification du "wrapper" au
sujet de laquelle j'avais eu une réponse
dans un poste précédent mais je n'avais pas bien tout saisi.
Peut-on en savoir un peu plus ? Merci
YLC
Eric Brunel
Tkinter n'est en fait qu'un "wrapper" autour d'un autre langage qui
s'appelle tcl/tk. En fait, quand on crée le premier widget Tkinter, il
lance un autre interpréteur pour tcl/tk qui va gérer tout le côté
graphique. Donc en fait, Tkinter suit les évolutions du langage tcl/tk,
avec toutefois toujours un petit retard.
Or, la dernière version de tcl/tk - 8.5 - est une *grosse* évolution du
langage, en particulier au niveau graphique justement. Les widgets tk
existaient depuis fort longtemps et avaient un look franchement obsolète
(en plus subjectif: moche...). De plus, beaucoup de types de widgets très
courants aujourd'hui n'étaient pas inclus dans le langage lui-même, mais
demandaient des extensions: par exemple, pas de tableau multi-colonnes, ni
d'arbres, ni même de panneaux à onglets, etc... Avec tcl/tk 8.5, tout ça a
été revu avec l'intégration dans le langage d'une extension appelée ttk
(pour "themed tk", je crois...), qui introduit pratiquement tous les
widgets qui manquaient, et de plus avec un look plus moderne (version
subjective: plus joli...), et surtout respectant le look natif quand c'est
possible. Pour se faire une idée, voir là:
http://tktable.sourceforge.net/tile/screenshots/unix.html
Cette version est malheureusement assez récente, et les nouveaux widgets
(ceux de ttk) n'avaient pas encore été intégrés dans le module Python
Tkinter. Jusqu'à... hier! Les prochaines versions de Python qui sortiront
inclueront donc nativement le support des widgets ttk dans Tkinter. Pour
les anciennes versions, il est toutefois possible de télécharger un module
additionnel ici:
http://gpolo.ath.cx:81/projects/pyttk/
C'est précisément ce module qui est maintenant intégré dans Tkinter, donc
normalement, pas de problème pour les évolutions. Il faudra par contre
bien sûr un Python utilisant la version 8.5 de tcl/tk. C'est le cas pour
la version Windows téléchargée de python.org. Pour les distributions "clef
en main" comme ActivePython ou autre, j'avoue que je ne sais pas...
Voilà. J'espère que c'est plus clair.
yves...@gmail.com
Dès que j'ai du temps je me penche là-dessus.
YLC
OdarR
> python -c "print ''.join([chr(154 - ord(c)) for c in
> 'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
c'est pythonic ça ?
sauvage! :-)
Olivier
Michel Claveau - NoSpam SVP ; merci
> Tkinter n'est en fait qu'un "wrapper" autour d'un autre langage qui
> s'appelle tcl/tk.
J'en profite pour glisser un petit exemple de code, qui montre comment
utiliser le langage TCL depuis Python (grâce à TKinter).
Je sais, personne n'en a rien à cirer. Mais, je m'étais intéressé au
problème il y a quelques temps. Alors je capitalise sur ce temps
perdu...
@-salutations
--
Michel Claveau
import Tkinter
tcl=Tkinter.Tk()
tcl.withdraw()
tcl.eval("puts hello")
tcl.eval("set a 123")
tcl.eval("set b 1000")
tcl.eval("puts $a")
tcl.eval("puts $b")
tcl.eval("set c [expr {$a + $b}]")
tcl.eval("puts $c")
tcl.eval('puts "a + b = $c"')
t='''set aa 789
set bb 9000
puts $aa
puts $bb
set cc [expr {$aa + $bb}]
puts $cc
puts \"aa + bb = $cc\" '''
tcl.eval(t)
OdarR
wrote:
Bon, et finalement c'est lequel qu'il faut préférrer si on veut pas se
casser la tête et en rester à un GUI simple mais fonctionnel, et multi-
plateforme (Win, Mac 'Aqua') ?
Olivier
Eric Brunel
<noZ....@ZZ.ZsvpZ.com> wrote:
> Bonsoir !
>
>> Tkinter n'est en fait qu'un "wrapper" autour d'un autre langage qui
>> s'appelle tcl/tk.
>
> J'en profite pour glisser un petit exemple de code, qui montre comment
> utiliser le langage TCL depuis Python (grâce à TKinter).
Je ne résiste pas, j'ai encore plus rigolo: une interaction entre Python
et tcl/tk beaucoup plus poussée que ce qui est fait dans Tkinter. Le code
brut de fonderie:
----------------------------------------
from Tkinter import *
class MyText(Text):
procTmpl = "".join([
'switch $command {\n',
' insert { eval "%s $args" }\n',
' delete { eval "%s $args" }\n',
' default { eval "%s $command $args" }\n',
'}\n'
])
def __init__(self, *args, **options):
Text.__init__(self, *args, **options)
self._newW = self._w[:-len(self._name)] + '_MyText__' + self._name
self.tk.call('rename', self._w, self._newW)
insCallback = self._register(self.insert)
delCallback = self._register(self.delete)
procBody = MyText.procTmpl % (insCallback, delCallback, self._newW)
self.tk.call("proc", self._w, "command args", procBody)
def insert(self, *args):
return self.tk.call((self._newW, "insert") + args)
def delete(self, *args):
self.tk.call((self._newW, "delete") + args)
----------------------------------------
Maintenant, le quiz du jour: à quoi ça peut bien servir? ;-)
> Je sais, personne n'en a rien à cirer. Mais, je m'étais intéressé au
> problème il y a quelques temps. Alors je capitalise sur ce temps perdu...
Mmmmm... Pas mieux en fait...
Michel Claveau - NoSpam SVP ; merci
> lequel qu'il faut préférer si on veut pas se casser la tête et en
> rester à un GUI simple mais fonctionnel,
PLUIE3. Simple, mais avec des possibilités d'extensions/évolutions
intéressantes.
> et multi-plateforme (Win, Mac 'Aqua') ?
Aïe. PLUIE fonctionne uniquement avec la famille Windows. Et encore,
uniquement sur les Windows à noyau NT avec GUI (donc, pas sur les
Win-9x, ni sur les CE, ni sur les éditions "Mobile", ni sur Core).
@-salutations
--
Michel Claveau
Eric Brunel
Ah ben ça on va avoir du mal à choisir à ta place... Tout ça dépend de tes
objectifs, de tes habitudes et de plein d'autres choses qui te sont
personnelles.
Pour ma part, mon choix a été guidé par plusieurs critères:
- D'abord, je ne voulais pas de bibliothèque monstrueuse qui réinventait
l'eau tiède et redéfinissait tous les widgets sans s'occuper de la
plateforme courante. Donc PyQt/QT et PyGtk/GTK étaient out...
- Restaient donc en gros wxPython et Tkinter. Le fait est que j'avais
commencé à utiliser le second il y a longtemps et que j'y étais plus
habitué. Cela dit, même aujourd'hui, je pense que je referais le même
choix, tout simplement parce que je n'arrive pas à me faire à l'API
wxPython. Je trouve ça trop compliqué, avec trop de choses qui n'ont
finalement pas grand chose à voir avec ce que je veux mettre dans ma GUI.
J'avoue que j'ai un peu oublié comment on fait en wxPython (et j'ai aussi
un peu la flemme de chercher...), mais quelque chose d'hyper-simple en
Tkinter comme ça:
from Tkinter import *
root = Tk()
def commande_bouton():
print 'coin!'
Button(root, text='Coin!', command=commande_bouton).pack()
root.mainloop()
est - si mes souvenirs sont bons - *beaucoup* plus compliqué à coder avec
wxPython.
Après plein d'autres critères peuvent entrer en compte, comme par exemple
la disponibilité d'un outil de dessin pour la GUI. Personnellement, ça ne
m'intéresse pas: j'en ai essayé beaucoup, et à chaque fois, j'ai fini par
vouloir faire quelque chose que le toolkit savait faire, mais pas l'outil
de dessin. Mais je sais qu'il y a des gens pour qui c'est impensable de
coder une GUI à la main. Et dans ce cas là, Tkinter risque d'être out
aussi, parce qu'à ma connaissance, un tel outil n'existe pas (à part
quelques vieux tromblons, voire - horreur! - des outils payants...).
Donc en gros, c'est à toi de définir tes critères, de faire des recherches
sur les toolkits, et éventuellement de poser quelques questions ici ou
ailleurs s'il y a des choses que tu ne trouves pas.
Méta-MCI (MVP)
> je n'arrive pas à me faire à l'API wxPython. Je trouve ça trop
> compliqué, avec trop de choses qui...
Et, je rajouterais que wxpython m'a posé suffisamment de problèmes de
versions, et de conflit entre les versions utilisées en développement et
les versions nécessitées par d'autres logiciels (sous Python).
De plus, pour ceux qui ont besoin de portabilité, il y a des choses qui,
dans wx, ne tournent que dans certains OS.
@-salutations
--
MCI
OdarR
wrote:
Merci pour vos conseils, les gars.
ça tombe bien, je comptais creuser un peu Tk, j'ai plein de doc papier
sous la main (Tkinter, ça se prononce "té ka inne-tère", ou "té kinne-
tère" ? ;-)
j'espère que ce sera pas trop kinne-tère surprise.
Olivier
OdarR
bel effort et merci, mais je tiens de plus en plus à investir le peu
de temps qu'il me reste à apprendre dans du multi-plateforme (d'où
déjà le choix python).
pour le gui c'est pareil. je touche comme beaucoup de monde à xp,
unix, linux, mac.
Olivier
Christophe
> On Thu, 05 Feb 2009 09:32:17 +0100, OdarR <olivie...@gmail.com> wrote:
>
>> On 23 jan, 13:32, "Méta-MCI \(MVP\)" <enleverlesX.X...@XmclaveauX.com>
>> wrote:
>>> Bonjour !
>>>
>>> Malgré qu'il soit en anglais, cet article pourrait intéresser des
>>> pythonneux :
>>> http://ojs.pythonpapers.org/index.php/tpp/article/view/61/57
>>> --
>>> @-salutations
>>> --
>>> Michel Claveau
>>
>> Bon, et finalement c'est lequel qu'il faut préférrer si on veut pas se
>> casser la tête et en rester à un GUI simple mais fonctionnel, et multi-
>> plateforme (Win, Mac 'Aqua') ?
>
> Ah ben ça on va avoir du mal à choisir à ta place... Tout ça dépend de
> tes objectifs, de tes habitudes et de plein d'autres choses qui te sont
> personnelles.
>
> Pour ma part, mon choix a été guidé par plusieurs critères:
> - D'abord, je ne voulais pas de bibliothèque monstrueuse qui réinventait
> l'eau tiède et redéfinissait tous les widgets sans s'occuper de la
> plateforme courante. Donc PyQt/QT et PyGtk/GTK étaient out...
Ce n'est plus d'actualité pour PyQt quand même. L'intégration de ce
dernier est très très bien faite.
> - Restaient donc en gros wxPython et Tkinter. Le fait est que j'avais
> commencé à utiliser le second il y a longtemps et que j'y étais plus
> habitué. Cela dit, même aujourd'hui, je pense que je referais le même
> choix, tout simplement parce que je n'arrive pas à me faire à l'API
> wxPython. Je trouve ça trop compliqué, avec trop de choses qui n'ont
> finalement pas grand chose à voir avec ce que je veux mettre dans ma
> GUI.
Je suis parfaitement d'accord avec ce choix. Je trouve l'API wx
particulièrement lourde que ce soit en C++ ou en Python (qui au final la
réplique très précisément). Cette API me rappelle furieusement l'API
Win32 elle même en fait ce qui n'est pas un gage de qualité :)
Michel Claveau - NoSpam SVP ; merci
> me rappelle furieusement l'API Win32
De quelle API parles-tu, précisément ? Parce que, dans Windows, des API
GUI, il y en a plusieurs. Des anciennes API de Win-9x (qui fonctionnent
encore, 10 ans après leur arrêt), à Silverlight, en passant par WPF,
Direct-X, DA, etc. On a l'embarras du choix.
Perso, j'ai opté, avec PLUIE, pour DHTML+DA.
Pour en revenir à wx, je trouve qu'il ressemble aux API de Win-3.1 ;
donc de plus de 15 ans...
@-salutations
--
Michel Claveau
Christophe
> Bonsoir !
>
>> me rappelle furieusement l'API Win32
>
> De quelle API parles-tu, précisément ? Parce que, dans Windows, des API
La vielle, l'API Win32 pour moi c'est celle qui a été introduite avec le
premier OS Microsoft 32bit, le vénérable Windows 95 lui même. Sans doute
que j'ai pris cette habitude car à l'époque, on l'opposait à l'API 16
bits de cette façon.
> GUI, il y en a plusieurs. Des anciennes API de Win-9x (qui fonctionnent
> encore, 10 ans après leur arrêt), à Silverlight, en passant par WPF,
> Direct-X, DA, etc. On a l'embarras du choix.
> Perso, j'ai opté, avec PLUIE, pour DHTML+DA.
>
> Pour en revenir à wx, je trouve qu'il ressemble aux API de Win-3.1 ;
> donc de plus de 15 ans...
Mmm, c'est trop loin pour moi, je ne faisais que du DOS directement à
l'époque mais c'est vrai que l'API des Win9x devait ressembler pas mal à
celle de Win 3.1 si je me souviens bien.
Eric Brunel
wrote:
> Eric Brunel a écrit :
>> - D'abord, je ne voulais pas de bibliothèque monstrueuse qui
>> réinventait l'eau tiède et redéfinissait tous les widgets sans
>> s'occuper de la plateforme courante. Donc PyQt/QT et PyGtk/GTK étaient
>> out...
>
> Ce n'est plus d'actualité pour PyQt quand même. L'intégration de ce
> dernier est très très bien faite.
Là, il faut que tu m'expliques: pour moi, QT est une bibliothèque qui
redéfinit intégralement tous les widgets et ne s'appuie pas sur ceux de la
plateforme courante. J'ai d'ailleurs déjà vu des applications faites avec
QT sur un Mac, et ça ne le fait (faisait?) pas du tout: les widgets
n'avaient ni le look, ni le fonctionnement usuel, et l'application avait
l'air bizarre. Mais peut-être était-ce sur une vieille version...?
Christophe
> On Thu, 05 Feb 2009 12:33:00 +0100, Christophe <chris.c...@free.fr>
> wrote:
>> Eric Brunel a écrit :
>>> - D'abord, je ne voulais pas de bibliothèque monstrueuse qui
>>> réinventait l'eau tiède et redéfinissait tous les widgets sans
>>> s'occuper de la plateforme courante. Donc PyQt/QT et PyGtk/GTK
>>> étaient out...
>>
>> Ce n'est plus d'actualité pour PyQt quand même. L'intégration de ce
>> dernier est très très bien faite.
>
> Là, il faut que tu m'expliques: pour moi, QT est une bibliothèque qui
> redéfinit intégralement tous les widgets et ne s'appuie pas sur ceux de
> la plateforme courante. J'ai d'ailleurs déjà vu des applications faites
> avec QT sur un Mac, et ça ne le fait (faisait?) pas du tout: les widgets
> n'avaient ni le look, ni le fonctionnement usuel, et l'application avait
> l'air bizarre. Mais peut-être était-ce sur une vieille version...?
Oui, peut-être n'est ce pas ? Théoriquement depuis la version 3.1 même.
http://doc.trolltech.com/3.3/qtmac-as-native.html
Cette page date de 2005 déjà. Le temps passe si vite :)