Parmi les nouveautés pour Tcl, il y a une structure de données dictionnaire, le support des grands entiers, les fonctions anonymes, la gestion des packages par module. Pour Tk, il y a l'adjonction d'un moteur de thèmes (permettant de se passer du look très épuré de Motif), les fontes anticrénelage sous X11, de nouveaux widgets intégrés directement dans le noyau (onglets, combobox, listes arborescentes et barres de progression) et les fenêtres transparentes.
NdM : merci à dark_moule pour sa contribution (cf. suite de la dépêche).
![[en]](../images/en.png)
L'annonce sur comp.lang.tcl (193 hits)-
La liste détaillée des changements (218 hits)
-
Le site officiel (444 hits)
-
Copies d'écran avec le moteur de thèmes (1360 hits)
-
La distribution tout en un eTcl (294 hits)
-
La distribution ActiveTcl (208 hits)
> Lire la dépêche (8 commentaires, moyenne: 1,8).
Vous avez demandé le commentaire #892403.
Run by 
Cette page a été générée par Templeet en 0.0455s (dont 0.0047 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Et pour Python/Tkinter ? :)
Je croyais que le développement de Tcl/Tk était au point mort, mais cette nouvelle version est vraiment la bienvenue car elle comble des lacunes, surtout au niveau de l'apparence des widgets sous GNU/Linux.
Je n'ai jamais programmé en Tcl/Tk, mais j'ai déjà fait quelques petits programmes en Python/Tkinter (bindings Python pour utiliser Tk), aussi je me demandais si Tkinter pourra bientôt profiter des améliorations de Tk.
Ça mettrait aussi fin aux modules "add-ons" tels que Tix ou Pmw, qui ajoutent de nouveaux widgets mais d'une façon plus ou moins cohérente malheureusement :/
@Jul
Je suis d'accord avec toi quand tu dis que la programmation d'interface est facilitée, mais la gestion des d'évènements est vraiment basique...
Ben c'est le principe même de la programmation événementielle, que l'on retrouve dans tous les toolkits graphiques (du moins, à ma connaissance)...
Malheureusement en Tk on ne peut pas "attacher" des données aux évènements, contrairement à GTK+ ou Qt qui intègrent le principe des signaux.
Tk est plus simple, mais aussi beaucoup plus limité.
À moins que tu voulais dire que Tk était un précurseur dans ce domaine, GTK+ et Qt étant plus récents ?
[^]Re: Et pour Python/Tkinter ? :)
À moins que tu voulais dire que Tk était un précurseur dans ce domaine, GTK+ et Qt étant plus récents ?
Tout à fait mon bon monsieur, tel était l'esprit de ma phrase.
Malheureusement en Tk on ne peut pas "attacher" des données aux évènements, contrairement à GTK+ ou Qt qui intègrent le principe des signaux.
On peut mettre à jour des widgets (de manière limité) en fonction de la valeur de variables (option variable des widgets).
Il me semble aussi que comme le tie de perl on peut greffer des callbacks sur des valeurs.
Si mes souvenirs sont exacts, on peut donc simuler les signaux avec un variable ^^ surveillée.
[^]Re: Et pour Python/Tkinter ? :)
Évidemment, Tk intègre la notion d'attachement de signaux. C'est la commande "bind". On attache un événement (appui sur une touche, entrée de la souris, destruction d'un widget, ...) pour un widget ou plusieurs, à l'exécution d'un morceau de code.
C'est depuis l'origine je pense dans Tk. Par contre, il est très courant que l'on est pas besoin d'aller jusque là, car les widgets courants (boutons, entrée de texte) intègrent des binding par défaut.
Les détails ici : http://fr.wikibooks.org/wiki/Vos_premiers_pas_en_Tk ou là http://www.linbox.com/ucome.rvt/any/fr/Ressources/Cours/tcl/(...) .
Les vrais limites de tk ne sont pas là. Pour moi la vraie limite étaient la non thémabilité de tk (mais avec 8.5 c'est fini), la difficulté d'avoir un look unique même entre 2 linux (pb de fontes). Il manquait aussi quelques widgets courants que l'on trouvait en librairie et qui sont maintenant intégrés (combobox, widget arbre, ...).