Python 2.5 est sorti.
Et... c'est là : http://www.python.org/2.5
Python 2.5 est sorti.
Et... c'est là : http://www.python.org/2.5
Python 2.5 est sorti.
Et... c'est là : http://www.python.org/2.5
Python 2.5 est sorti.
Et... c'est là : http://www.python.org/2.5
Bonne Nouvelle !
Cela dit, me trompe-je, ou le "RAD" avec python, sans se poser de question,
et avec la portabilité en prime, ce n'est pas pour cette version ?
Sauf erreur :
1/ Il n'y a pas de toolkit graphique intégré, sinon TkInter qui est tout de
même limité, pas pratique, moche et encore moche !
2/ Il n'y a pas non plus d'environnement de développement "moderne" (avec
intellisense, débuggeur intégré, et un designer pour l'interface graphique)
Dommage, non ?
Python 2.5 est sorti.
Et... c'est là : http://www.python.org/2.5
Bonne Nouvelle !
Cela dit, me trompe-je, ou le "RAD" avec python, sans se poser de question,
et avec la portabilité en prime, ce n'est pas pour cette version ?
Sauf erreur :
1/ Il n'y a pas de toolkit graphique intégré, sinon TkInter qui est tout de
même limité, pas pratique, moche et encore moche !
2/ Il n'y a pas non plus d'environnement de développement "moderne" (avec
intellisense, débuggeur intégré, et un designer pour l'interface graphique)
Dommage, non ?
Python 2.5 est sorti.
Et... c'est là : http://www.python.org/2.5
Bonne Nouvelle !
Cela dit, me trompe-je, ou le "RAD" avec python, sans se poser de question,
et avec la portabilité en prime, ce n'est pas pour cette version ?
Sauf erreur :
1/ Il n'y a pas de toolkit graphique intégré, sinon TkInter qui est tout de
même limité, pas pratique, moche et encore moche !
2/ Il n'y a pas non plus d'environnement de développement "moderne" (avec
intellisense, débuggeur intégré, et un designer pour l'interface graphique)
Dommage, non ?
1/ Il n'y a pas de toolkit graphique intégré, sinon TkInter qui est tout de
même limité, pas pratique, moche et encore moche !
Je n'aime pas spécialement Tk non plus, mais c'est probablement la
meilleure solution "minimale". En ce qui me concerne, le simple fait
d'avoir un GUI toolkit dans la biblio standard est déjà discutable...
En ce qui concerne les "environnement de développement "moderne"",
personnellement,j'attend toujours d'en trouver aussi puissant et
versatile que Emacs. Accessoirement, je travaille avec une bonne
demi-douzaine de langages (Python, PHP, javascript, C, bash, (x|ht)ml,
css, SQL, LDAP etc), et avoir à utiliser autant d'IDE "modernes" que de
langage serait une horreur.
1/ Il n'y a pas de toolkit graphique intégré, sinon TkInter qui est tout de
même limité, pas pratique, moche et encore moche !
Je n'aime pas spécialement Tk non plus, mais c'est probablement la
meilleure solution "minimale". En ce qui me concerne, le simple fait
d'avoir un GUI toolkit dans la biblio standard est déjà discutable...
En ce qui concerne les "environnement de développement "moderne"",
personnellement,j'attend toujours d'en trouver aussi puissant et
versatile que Emacs. Accessoirement, je travaille avec une bonne
demi-douzaine de langages (Python, PHP, javascript, C, bash, (x|ht)ml,
css, SQL, LDAP etc), et avoir à utiliser autant d'IDE "modernes" que de
langage serait une horreur.
1/ Il n'y a pas de toolkit graphique intégré, sinon TkInter qui est tout de
même limité, pas pratique, moche et encore moche !
Je n'aime pas spécialement Tk non plus, mais c'est probablement la
meilleure solution "minimale". En ce qui me concerne, le simple fait
d'avoir un GUI toolkit dans la biblio standard est déjà discutable...
En ce qui concerne les "environnement de développement "moderne"",
personnellement,j'attend toujours d'en trouver aussi puissant et
versatile que Emacs. Accessoirement, je travaille avec une bonne
demi-douzaine de langages (Python, PHP, javascript, C, bash, (x|ht)ml,
css, SQL, LDAP etc), et avoir à utiliser autant d'IDE "modernes" que de
langage serait une horreur.
Si tu veux dire par là un outil RAD intégré à la bibliothèque standard,
je pense que ce n'est effectivement ni pour cette version, ni pour les
suivantes.
Je n'aime pas spécialement Tk non plus, mais c'est probablement la
meilleure solution "minimale".
En ce qui me concerne, le simple fait
d'avoir un GUI toolkit dans la biblio standard est déjà discutable...
A part quelques technos propriétaires et non portables (Delphi, VB etc)
où c'est le langage qui est intégré à l'IDE plus que l'inverse, aucun
langage n'intègre ce genre de choses dans sa bibliothèque standard.
En ce qui concerne les "environnement de développement "moderne"",
personnellement,j'attend toujours d'en trouver aussi puissant et
versatile que Emacs. Accessoirement, je travaille avec une bonne
demi-douzaine de langages (Python, PHP, javascript, C, bash, (x|ht)ml,
css, SQL, LDAP etc), et avoir à utiliser autant d'IDE "modernes" que de
langage serait une horreur. Enfin, je n'écris plus de client lourd
depuis plusieurs années (ligne de commande ou web uniquement), donc je
n'ai absolument pas l'usage d'un GUI designer.Dommage, non ?
Pas pour moi.
Si tu veux dire par là un outil RAD intégré à la bibliothèque standard,
je pense que ce n'est effectivement ni pour cette version, ni pour les
suivantes.
Je n'aime pas spécialement Tk non plus, mais c'est probablement la
meilleure solution "minimale".
En ce qui me concerne, le simple fait
d'avoir un GUI toolkit dans la biblio standard est déjà discutable...
A part quelques technos propriétaires et non portables (Delphi, VB etc)
où c'est le langage qui est intégré à l'IDE plus que l'inverse, aucun
langage n'intègre ce genre de choses dans sa bibliothèque standard.
En ce qui concerne les "environnement de développement "moderne"",
personnellement,j'attend toujours d'en trouver aussi puissant et
versatile que Emacs. Accessoirement, je travaille avec une bonne
demi-douzaine de langages (Python, PHP, javascript, C, bash, (x|ht)ml,
css, SQL, LDAP etc), et avoir à utiliser autant d'IDE "modernes" que de
langage serait une horreur. Enfin, je n'écris plus de client lourd
depuis plusieurs années (ligne de commande ou web uniquement), donc je
n'ai absolument pas l'usage d'un GUI designer.
Dommage, non ?
Pas pour moi.
Si tu veux dire par là un outil RAD intégré à la bibliothèque standard,
je pense que ce n'est effectivement ni pour cette version, ni pour les
suivantes.
Je n'aime pas spécialement Tk non plus, mais c'est probablement la
meilleure solution "minimale".
En ce qui me concerne, le simple fait
d'avoir un GUI toolkit dans la biblio standard est déjà discutable...
A part quelques technos propriétaires et non portables (Delphi, VB etc)
où c'est le langage qui est intégré à l'IDE plus que l'inverse, aucun
langage n'intègre ce genre de choses dans sa bibliothèque standard.
En ce qui concerne les "environnement de développement "moderne"",
personnellement,j'attend toujours d'en trouver aussi puissant et
versatile que Emacs. Accessoirement, je travaille avec une bonne
demi-douzaine de langages (Python, PHP, javascript, C, bash, (x|ht)ml,
css, SQL, LDAP etc), et avoir à utiliser autant d'IDE "modernes" que de
langage serait une horreur. Enfin, je n'écris plus de client lourd
depuis plusieurs années (ligne de commande ou web uniquement), donc je
n'ai absolument pas l'usage d'un GUI designer.Dommage, non ?
Pas pour moi.
Certes. Pas pour toi. Mais d'autres que toi réalisent des clients lourds. Et
aiment les EDI "à la Delphi" qui remportent un vif succès. Un bon EDI aide
grandement à rendre un langage populaire !
Pour les clients lourds, FreePascal dans l'environnement Lazarus :
Certes. Pas pour toi. Mais d'autres que toi réalisent des clients lourds. Et
aiment les EDI "à la Delphi" qui remportent un vif succès. Un bon EDI aide
grandement à rendre un langage populaire !
Pour les clients lourds, FreePascal dans l'environnement Lazarus :
Certes. Pas pour toi. Mais d'autres que toi réalisent des clients lourds. Et
aiment les EDI "à la Delphi" qui remportent un vif succès. Un bon EDI aide
grandement à rendre un langage populaire !
Pour les clients lourds, FreePascal dans l'environnement Lazarus :
Python 2.5 est sorti.
Et... c'est là : http://www.python.org/2.5
Bonne Nouvelle !
Cela dit, me trompe-je, ou le "RAD" avec python, sans se poser de question,
et avec la portabilité en prime, ce n'est pas pour cette version ?
Sauf erreur :
1/ Il n'y a pas de toolkit graphique intégré, sinon TkInter qui est tout de
même limité, pas pratique, moche et encore moche !
2/ Il n'y a pas non plus d'environnement de développement "moderne" (avec
intellisense, débuggeur intégré, et un designer pour l'interface graphique)
? Quelque chose comme #Develop (
http://www.icsharpcode.com/OpenSource/SD/Default.aspx )
Dommage, non ?
Python 2.5 est sorti.
Et... c'est là : http://www.python.org/2.5
Bonne Nouvelle !
Cela dit, me trompe-je, ou le "RAD" avec python, sans se poser de question,
et avec la portabilité en prime, ce n'est pas pour cette version ?
Sauf erreur :
1/ Il n'y a pas de toolkit graphique intégré, sinon TkInter qui est tout de
même limité, pas pratique, moche et encore moche !
2/ Il n'y a pas non plus d'environnement de développement "moderne" (avec
intellisense, débuggeur intégré, et un designer pour l'interface graphique)
? Quelque chose comme #Develop (
http://www.icsharpcode.com/OpenSource/SD/Default.aspx )
Dommage, non ?
Python 2.5 est sorti.
Et... c'est là : http://www.python.org/2.5
Bonne Nouvelle !
Cela dit, me trompe-je, ou le "RAD" avec python, sans se poser de question,
et avec la portabilité en prime, ce n'est pas pour cette version ?
Sauf erreur :
1/ Il n'y a pas de toolkit graphique intégré, sinon TkInter qui est tout de
même limité, pas pratique, moche et encore moche !
2/ Il n'y a pas non plus d'environnement de développement "moderne" (avec
intellisense, débuggeur intégré, et un designer pour l'interface graphique)
? Quelque chose comme #Develop (
http://www.icsharpcode.com/OpenSource/SD/Default.aspx )
Dommage, non ?
Si tu veux dire par là un outil RAD intégré à la bibliothèque standard,
je pense que ce n'est effectivement ni pour cette version, ni pour les
suivantes.
Je ne comprends pas trop ce que "RAD intégré à la bibliotheque standard"
peut signifier ?
En schématisant, sous l'étiquette "Python", on trouve un
langage et ses bibliothèques.
Mon (gros) regret est de ne pas trouver "en
standard" autre chose que Tk pour l'interface graphique. Un autre gros
regret est de ne pas trouver mieux qu'IDLE comme environnement de
développement.Je n'aime pas spécialement Tk non plus, mais c'est probablement la
meilleure solution "minimale".
Tk en meilleure solution minimale ? Il va être content Tk ;-) Mais si par
"minimale" il faut comprendre "fonctionnant sur autant d'OS majeurs que le
langage", alors il y a, me semble-t-il, beaucoup d'autres toolkit : GTK, QT,
wxWindows, et d'autres... Tous meilleurs que Tk, non ?
En ce qui me concerne, le simple fait
d'avoir un GUI toolkit dans la biblio standard est déjà discutable...
C'est le cas aujourd'hui avec Tkinter qui ne satisfait sans doute totalement
ni les tenants d'un toolkit dans la biblio standard, ni les autres... Autant
intégrer un meilleur toolkit dans la biblio, ce qui ne gènerait en rien ceux
qui ne font usage d'aucun toolkit
tout en ne peinalisant pas ceux qui aurait
préféré n'importe quel autre (qu'il resterait possible d'exploiter comme
aujourd'hui)
A part quelques technos propriétaires et non portables (Delphi, VB etc)
où c'est le langage qui est intégré à l'IDE plus que l'inverse, aucun
langage n'intègre ce genre de choses dans sa bibliothèque standard.
A te lire, on pourrait croire que l'IDE intègre le langage qui intègre la
bibliothèque standard ?
AMHA, c'est plutôt l'inverse !
"langage qui est intégré à l'IDE plus que l'inverse" : que dire alors de
tous les EDI "non Microsoft" (Borland, SharpDevelop) dédié au Framework .Net
? Que dire alors aussi des EDI pour la plateforme Java ?
Et un jour, pour
Mono ? J'en oublie ? Pour les cas cités, un EDI vise au moins un "Framework"
qui est exploité via un (ou plusieurs!) langage(s) et compilateur(s). Le
langage, et plus encore le Framework, existe totalement en dehors de tel ou
tel EDI. Pour preuve : tu peux utiliser un simple editeur (ou Emacs) pour
coder, et compiler "à la main" en faisant appel au complilateur via la
"ligne de commande".
"aucun langage n'intègre ce genre de choses dans sa bibliothèque standard" :
si tu penses au Framework .Net, à Java, à Mono, alors tu établis une toute
autre relation entre un langage et une "bibliotheque standard" : le langage
n'intègre pas "sa" bibliotheque standard ! Au contraire, ce n'est pas le
langage qui prime, mais la "bibliotheque" : un langage ne fait qu'exploiter
une "bibliothèque" (Framework) qui peut-être utilisées par plusieurs
langages.
En ce qui concerne les "environnement de développement "moderne"",
personnellement,j'attend toujours d'en trouver aussi puissant et
versatile que Emacs. Accessoirement, je travaille avec une bonne
demi-douzaine de langages (Python, PHP, javascript, C, bash, (x|ht)ml,
css, SQL, LDAP etc), et avoir à utiliser autant d'IDE "modernes" que de
langage serait une horreur. Enfin, je n'écris plus de client lourd
depuis plusieurs années (ligne de commande ou web uniquement), donc je
n'ai absolument pas l'usage d'un GUI designer.Dommage, non ?
Pas pour moi.
Certes. Pas pour toi. Mais d'autres que toi réalisent des clients lourds.
Et
aiment les EDI "à la Delphi"
Si tu veux dire par là un outil RAD intégré à la bibliothèque standard,
je pense que ce n'est effectivement ni pour cette version, ni pour les
suivantes.
Je ne comprends pas trop ce que "RAD intégré à la bibliotheque standard"
peut signifier ?
En schématisant, sous l'étiquette "Python", on trouve un
langage et ses bibliothèques.
Mon (gros) regret est de ne pas trouver "en
standard" autre chose que Tk pour l'interface graphique. Un autre gros
regret est de ne pas trouver mieux qu'IDLE comme environnement de
développement.
Je n'aime pas spécialement Tk non plus, mais c'est probablement la
meilleure solution "minimale".
Tk en meilleure solution minimale ? Il va être content Tk ;-) Mais si par
"minimale" il faut comprendre "fonctionnant sur autant d'OS majeurs que le
langage", alors il y a, me semble-t-il, beaucoup d'autres toolkit : GTK, QT,
wxWindows, et d'autres... Tous meilleurs que Tk, non ?
En ce qui me concerne, le simple fait
d'avoir un GUI toolkit dans la biblio standard est déjà discutable...
C'est le cas aujourd'hui avec Tkinter qui ne satisfait sans doute totalement
ni les tenants d'un toolkit dans la biblio standard, ni les autres... Autant
intégrer un meilleur toolkit dans la biblio, ce qui ne gènerait en rien ceux
qui ne font usage d'aucun toolkit
tout en ne peinalisant pas ceux qui aurait
préféré n'importe quel autre (qu'il resterait possible d'exploiter comme
aujourd'hui)
A part quelques technos propriétaires et non portables (Delphi, VB etc)
où c'est le langage qui est intégré à l'IDE plus que l'inverse, aucun
langage n'intègre ce genre de choses dans sa bibliothèque standard.
A te lire, on pourrait croire que l'IDE intègre le langage qui intègre la
bibliothèque standard ?
AMHA, c'est plutôt l'inverse !
"langage qui est intégré à l'IDE plus que l'inverse" : que dire alors de
tous les EDI "non Microsoft" (Borland, SharpDevelop) dédié au Framework .Net
? Que dire alors aussi des EDI pour la plateforme Java ?
Et un jour, pour
Mono ? J'en oublie ? Pour les cas cités, un EDI vise au moins un "Framework"
qui est exploité via un (ou plusieurs!) langage(s) et compilateur(s). Le
langage, et plus encore le Framework, existe totalement en dehors de tel ou
tel EDI. Pour preuve : tu peux utiliser un simple editeur (ou Emacs) pour
coder, et compiler "à la main" en faisant appel au complilateur via la
"ligne de commande".
"aucun langage n'intègre ce genre de choses dans sa bibliothèque standard" :
si tu penses au Framework .Net, à Java, à Mono, alors tu établis une toute
autre relation entre un langage et une "bibliotheque standard" : le langage
n'intègre pas "sa" bibliotheque standard ! Au contraire, ce n'est pas le
langage qui prime, mais la "bibliotheque" : un langage ne fait qu'exploiter
une "bibliothèque" (Framework) qui peut-être utilisées par plusieurs
langages.
En ce qui concerne les "environnement de développement "moderne"",
personnellement,j'attend toujours d'en trouver aussi puissant et
versatile que Emacs. Accessoirement, je travaille avec une bonne
demi-douzaine de langages (Python, PHP, javascript, C, bash, (x|ht)ml,
css, SQL, LDAP etc), et avoir à utiliser autant d'IDE "modernes" que de
langage serait une horreur. Enfin, je n'écris plus de client lourd
depuis plusieurs années (ligne de commande ou web uniquement), donc je
n'ai absolument pas l'usage d'un GUI designer.
Dommage, non ?
Pas pour moi.
Certes. Pas pour toi. Mais d'autres que toi réalisent des clients lourds.
Et
aiment les EDI "à la Delphi"
Si tu veux dire par là un outil RAD intégré à la bibliothèque standard,
je pense que ce n'est effectivement ni pour cette version, ni pour les
suivantes.
Je ne comprends pas trop ce que "RAD intégré à la bibliotheque standard"
peut signifier ?
En schématisant, sous l'étiquette "Python", on trouve un
langage et ses bibliothèques.
Mon (gros) regret est de ne pas trouver "en
standard" autre chose que Tk pour l'interface graphique. Un autre gros
regret est de ne pas trouver mieux qu'IDLE comme environnement de
développement.Je n'aime pas spécialement Tk non plus, mais c'est probablement la
meilleure solution "minimale".
Tk en meilleure solution minimale ? Il va être content Tk ;-) Mais si par
"minimale" il faut comprendre "fonctionnant sur autant d'OS majeurs que le
langage", alors il y a, me semble-t-il, beaucoup d'autres toolkit : GTK, QT,
wxWindows, et d'autres... Tous meilleurs que Tk, non ?
En ce qui me concerne, le simple fait
d'avoir un GUI toolkit dans la biblio standard est déjà discutable...
C'est le cas aujourd'hui avec Tkinter qui ne satisfait sans doute totalement
ni les tenants d'un toolkit dans la biblio standard, ni les autres... Autant
intégrer un meilleur toolkit dans la biblio, ce qui ne gènerait en rien ceux
qui ne font usage d'aucun toolkit
tout en ne peinalisant pas ceux qui aurait
préféré n'importe quel autre (qu'il resterait possible d'exploiter comme
aujourd'hui)
A part quelques technos propriétaires et non portables (Delphi, VB etc)
où c'est le langage qui est intégré à l'IDE plus que l'inverse, aucun
langage n'intègre ce genre de choses dans sa bibliothèque standard.
A te lire, on pourrait croire que l'IDE intègre le langage qui intègre la
bibliothèque standard ?
AMHA, c'est plutôt l'inverse !
"langage qui est intégré à l'IDE plus que l'inverse" : que dire alors de
tous les EDI "non Microsoft" (Borland, SharpDevelop) dédié au Framework .Net
? Que dire alors aussi des EDI pour la plateforme Java ?
Et un jour, pour
Mono ? J'en oublie ? Pour les cas cités, un EDI vise au moins un "Framework"
qui est exploité via un (ou plusieurs!) langage(s) et compilateur(s). Le
langage, et plus encore le Framework, existe totalement en dehors de tel ou
tel EDI. Pour preuve : tu peux utiliser un simple editeur (ou Emacs) pour
coder, et compiler "à la main" en faisant appel au complilateur via la
"ligne de commande".
"aucun langage n'intègre ce genre de choses dans sa bibliothèque standard" :
si tu penses au Framework .Net, à Java, à Mono, alors tu établis une toute
autre relation entre un langage et une "bibliotheque standard" : le langage
n'intègre pas "sa" bibliotheque standard ! Au contraire, ce n'est pas le
langage qui prime, mais la "bibliotheque" : un langage ne fait qu'exploiter
une "bibliothèque" (Framework) qui peut-être utilisées par plusieurs
langages.
En ce qui concerne les "environnement de développement "moderne"",
personnellement,j'attend toujours d'en trouver aussi puissant et
versatile que Emacs. Accessoirement, je travaille avec une bonne
demi-douzaine de langages (Python, PHP, javascript, C, bash, (x|ht)ml,
css, SQL, LDAP etc), et avoir à utiliser autant d'IDE "modernes" que de
langage serait une horreur. Enfin, je n'écris plus de client lourd
depuis plusieurs années (ligne de commande ou web uniquement), donc je
n'ai absolument pas l'usage d'un GUI designer.Dommage, non ?
Pas pour moi.
Certes. Pas pour toi. Mais d'autres que toi réalisent des clients lourds.
Et
aiment les EDI "à la Delphi"
non, ce qui serait dommage c'est que les développeurs du langage
s'occupent d'environnement graphique. On voit ce que ça donne quand
Guido donne ne serait-ce que son avis sur un framework web ;-)
Lol !
non, ce qui serait dommage c'est que les développeurs du langage
s'occupent d'environnement graphique. On voit ce que ça donne quand
Guido donne ne serait-ce que son avis sur un framework web ;-)
Lol !
non, ce qui serait dommage c'est que les développeurs du langage
s'occupent d'environnement graphique. On voit ce que ça donne quand
Guido donne ne serait-ce que son avis sur un framework web ;-)
Lol !
William Dode wrote:
(snip)non, ce qui serait dommage c'est que les développeurs du langage
s'occupent d'environnement graphique. On voit ce que ça donne quand
Guido donne ne serait-ce que son avis sur un framework web ;-)
Lol !
Effectivement, et avec tout le respect dû à notre BDFL, il y a des fois
où j'aime autant qu'il s'abstienne...
William Dode wrote:
(snip)
non, ce qui serait dommage c'est que les développeurs du langage
s'occupent d'environnement graphique. On voit ce que ça donne quand
Guido donne ne serait-ce que son avis sur un framework web ;-)
Lol !
Effectivement, et avec tout le respect dû à notre BDFL, il y a des fois
où j'aime autant qu'il s'abstienne...
William Dode wrote:
(snip)non, ce qui serait dommage c'est que les développeurs du langage
s'occupent d'environnement graphique. On voit ce que ça donne quand
Guido donne ne serait-ce que son avis sur un framework web ;-)
Lol !
Effectivement, et avec tout le respect dû à notre BDFL, il y a des fois
où j'aime autant qu'il s'abstienne...
PAQJS, GTK ne tourne pas sous MacOS, n'est pas simple à installer sous
Windows, et n'est pas nécessairement disponible sur tous les unices. La
situation n'est pas forcément très différente pour QT (minus les pb
d'installation sous Windows, mais plus les problèmes de licence) - et en
plus, c'est assez lourd. wxWidgets (ex wxWindows, merci MS) est le plus
portable du lot, mais si mon souvenir est bon, c'est un poids lourd
comparé à Tk.
Tout à fait exact. Mais une fois qu'on le maîtrise, on peut vraiment
PAQJS, GTK ne tourne pas sous MacOS, n'est pas simple à installer sous
Windows, et n'est pas nécessairement disponible sur tous les unices. La
situation n'est pas forcément très différente pour QT (minus les pb
d'installation sous Windows, mais plus les problèmes de licence) - et en
plus, c'est assez lourd. wxWidgets (ex wxWindows, merci MS) est le plus
portable du lot, mais si mon souvenir est bon, c'est un poids lourd
comparé à Tk.
Tout à fait exact. Mais une fois qu'on le maîtrise, on peut vraiment
PAQJS, GTK ne tourne pas sous MacOS, n'est pas simple à installer sous
Windows, et n'est pas nécessairement disponible sur tous les unices. La
situation n'est pas forcément très différente pour QT (minus les pb
d'installation sous Windows, mais plus les problèmes de licence) - et en
plus, c'est assez lourd. wxWidgets (ex wxWindows, merci MS) est le plus
portable du lot, mais si mon souvenir est bon, c'est un poids lourd
comparé à Tk.
Tout à fait exact. Mais une fois qu'on le maîtrise, on peut vraiment