Discussion :

[Anne_so2121]

Bonjour à tous

Désolé je ne savais pas trop ou poster ...
Je voudrais savoir ce que vous pensez du Tcl / Tk pour le developpement d'interfaces graphiques ?
Est-ce complètement dépassé ou toujours bien utile ?

Merci d'avance !!!!!

[Gamdwin]

De ce que j'en sais, c'est vieux.

Ce serait pas mieux de se tourner vers GTK ?
http://search.cpan.org/~tsch/Gtk2-1.081/Gtk2.pm


EDIT : apparemment, je sais mal. Je dois confondre avec une autre API : le site officiel est à jour, et la version 8.4.10 vient de sortir :
http://www.tcl.tk/
Quant au module CPAN qui va bien :
http://search.cpan.org/~vkon/TclTk-0.75/Tk.pm

[2Eurocents]

Bonjour,

Je voudrais savoir ce que vous pensez du Tcl / Tk pour le developpement d'interfaces graphiques ?
Est-ce complètement dépassé ou toujours bien utile ?

Il y a deux outils distincts, dans la doublette Tcl/Tk.

Il y a le langage de script Tcl, qui peut être assez efficace quand il est bien maîtrisé, mais qui n'est pas facile à maîtriser ...

Il y a aussi le kit graphique Tk. Celui-ci est utilisable indépendemment de Tcl (il y a, par exemple, l'excellent couple Perl/Tk).

Les interfaces réalisées avec Tk ne sont pas toujours top de top au niveau du look (parfois un peu vieillot, mais cela dépend aussi du talent du programmeur). Par contre, l'un des widgets de Tk peut parfois à lui seul justifier l'usage de ce kit : le widget Canvas.

Le widget Canvas permet de tracer des objets graphiques (polygones, ellipses, segments, etc.), et de les considérer comme de réels objets, avec possibilité de déplacement, altérations géométriques, changement de style, réaction aux événements clavier/souris. C'est idéal, par exemple, pour réaliser un schéma synoptique qui doit interagir avec l'utilisateur ou être mis à jour.

Voila ...

[Anne_so2121]

Merci pour vos réponses,

Je pense maitriser a peu pret ce langage car j'ai développé qq IHM avec, mais je voulais juste un avis général. Et surtout savoir si ce langage était toujours utilisé actuellement (pas seulement par moi koi... lol).

[HRS]

le fait qu'il soit régulièrement actualisé (dernière version récente)
sur plusieurs plateformes, indique qu'il est toujours d'actualité.

De plus Freewrap permet de faire un .exe indépendant. Interessant quand
on veut diffuser une appli sans l'environnement

comment interfacer un programme C avec le programme tcl/tk suivant
pour récupérer la saisie contrôlée ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
font create fcnax -family arial -weight bold -size 12
set commun {-relief sunken -font fcnax -validate all -invcmd bell}
proc Valider {champ longueur} {
   set a [regexp {^[0-9]*$} $champ]
   if {$a==0} {return 0} 
   return [expr [string length $champ]<=$longueur]
}
wm title . "Saisie "
wm geometry . 220x100
wm resizable . false false
label .lbassnum -text Assnum -font fcnax
eval entry .yassnum  -textvariable assnum -width 14 $commun -vcmd {{Valider %P 13}} 
pack .lbassnum .yassnum -side left -anchor nw -padx 5 -pady 15

[quicky2000]

Personellement ayant deja developpe des IHM et en Java et en Tk je prefere largement Java...en fait je n aime pas Tk parce qu il possede les meme inconvenients que TCL en particulier aucune verification du code avant l exectuion donc tous les problemes ne sont detectes qu a l execution etc
et autre gros reproche que je lui fais c est son manque de lisibilite par rapport aux langages comme java ou C que je trouve beaucoup mieux structures

Mais bon tout cela n engage que moi, apres les gouts et les couleurs ...

[Mathusalem]

Personellement ayant deja developpe des IHM et en Java et en Tk je prefere largement Java...en fait je n aime pas Tk parce qu il possede les meme inconvenients que TCL en particulier aucune verification du code avant l exectuion donc tous les problemes ne sont detectes qu a l execution etc
et autre gros reproche que je lui fais c est son manque de lisibilite par rapport aux langages comme java ou C que je trouve beaucoup mieux structures

Mais bon tout cela n engage que moi, apres les gouts et les couleurs ...

que veux-tu dire par "aucune vérification du code avant l'exécution" ?
il ne s'agit pas d'un langage compilé mais interprêté, tu ne peux pas le comparer à Java la dessus.

Ou alors j'ai rien compris, j'ai attaqué Tcl il y a une semaine

[quicky2000]

que veux-tu dire par "aucune vérification du code avant l'exécution" ?
il ne s'agit pas d'un langage compilé mais interprêté, tu ne peux pas le comparer à Java la dessus.

C est bien ce que je lui reproche !! c est d etre interprete

[sekaijin]

Il y a bien longtemps que je n'ai pas fais de tcl.
mais je pense que tcl tout comme tk sont encore bien vivant.

pour ma part tcl est une bonne colle pour des dev plus lourd en C++ (C)
bref je l'ai toujours utilisé ainsi. faire des package en C++ spécifique à mon activité et assembler le tout en tcl.
ainsi les assemblage peuvent évoluer sans recompiler le tout.

pour ce qui est de tk le gros avantage que je lui trouve c'est sa simplicité de mise en oeuvre. Je ne crois pas qu'il faille le comparer à GTK ou autre
Tk est pour moi un langage de macro graphique. un truc pour faire de petites interface. même si certain on fait de très belle chose avec je trouve que c'est dans ce contexte qu'il s'exprime le mieux.

et le fait que tcl soit interprété est justement sa force.
si le besoin de vérification se fait sentir au point de nécessité une analyse au préalable c'est le signe qu'il faut passer à un autre langage.

embarque un langage de script dans une appli est aussi un gros avantage pour automatiser certaine tâches.

A+JYT

[habilité]

Salut.

De ce que je connais de Tcl/Tk est qu'il est un langage script, donc interprêté. Cela signifie que Tcl-Tk ne supporte pas les très grosses applications. C'est la faiblesse de tous langages script. Toutefois, il est possible d'améliorer les performances, car l'interprêteur a du code déjà compilé à l'intérieur de son interprêteur. Cela favorise la vitesse d'analyse du code.

Une très grosse application écrite en tcl a tendance a faire exploser la mémoire de l'interprêteur, car il ne peux pas tout enmagasiner. Pourtant avec une grosse application, c'est exactement ce qu'on lui demande de faire sans le vouloir vraiment.

L'avantage d'un code compilé est qu'il s'execute au fur et à mesure si bien que cela libère de la mémoire, car le code objet (en code machine) suit le mode procédural pour fonctionner, c'est-à-dire l'execution des instructions les unes à la suite des autres.

Vous me direz que l'interprêteur agirait de la même façon qu'un compilateur avec son code précompilé. Cependant, ce n'est pas le cas. Il est possible qu'une instruction donnée au début peut-être réutilisée n'importe où au niveau du programme ce qui nécessite de garder malcontreusement tout en mémoire. D'où la principale difficulté d'un langage script. Pour contourner cet aspect là, on a pensé à introduire du code objet pour faciliter la réutilisation de code à l'intérieur de l'interprêteur. Toutefois, malgré ces améliorations les langages scripts pêchent par leur défaut de base à savoir la sauvegarde du code complet en mémoire.

1) Pour résoudre, une telle difficulté. Il serait intéressant d'écrire une grosse application en tcl (que nous saurions pas interprêtable) afin de la ramener par un convertisseur adéquat dans un langage compilable dans le but de la traduire. Cependant, comme le code n'a pas été analysé, il se peut que des erreurs malcontreuses viennent s'y glisser. C'est pourquoi, il est nécessaire de compartimenter un programme avec des fichiers à importer avec la commande source en tcl afin de le faire fonctionner par petit bout avant de le ramener en une seule application. Ainsi, l'application désirée aura été fractionnée par pièces (à regrouper par la suite). Voilà pour la pratique.


A+

[MichMiko]

J'utilise Tcl et Tk quotidiennement au boulot.
Tcl tout seul pour des scripts automatisés qui lancent des requêtes sur des SGBD et mailent les résultats aux intéressés, Tcl/Tk pour des interfaces de saisie.

J'ai fait du Delphi avant et un peu de Java, avec Tcl/Tk, je vais à peu près dix fois plus vite pour faire les mêmes choses... et avec beaucoup moins de lignes de code, donc plus facile à relire et à debugger.

[sekaijin]

Salut.

De ce que je connais de Tcl/Tk est qu'il est un langage script, donc interprêté. Cela signifie que Tcl-Tk ne supporte pas les très grosses applications. C'est la faiblesse de tous langages script. Toutefois, il est possible d'améliorer les performances, car l'interprêteur a du code déjà compilé à l'intérieur de son interprêteur. Cela favorise la vitesse d'analyse du code.

Une très grosse application écrite en tcl a tendance a faire exploser la mémoire de l'interprêteur, car il ne peux pas tout enmagasiner. Pourtant avec une grosse application, c'est exactement ce qu'on lui demande de faire sans le vouloir vraiment.

L'avantage d'un code compilé est qu'il s'execute au fur et à mesure si bien que cela libère de la mémoire, car le code objet (en code machine) suit le mode procédural pour fonctionner, c'est-à-dire l'execution des instructions les unes à la suite des autres.

Vous me direz que l'interprêteur agirait de la même façon qu'un compilateur avec son code précompilé. Cependant, ce n'est pas le cas. Il est possible qu'une instruction donnée au début peut-être réutilisée n'importe où au niveau du programme ce qui nécessite de garder malcontreusement tout en mémoire. D'où la principale difficulté d'un langage script. Pour contourner cet aspect là, on a pensé à introduire du code objet pour faciliter la réutilisation de code à l'intérieur de l'interprêteur. Toutefois, malgré ces améliorations les langages scripts pêchent par leur défaut de base à savoir la sauvegarde du code complet en mémoire.

1) Pour résoudre, une telle difficulté. Il serait intéressant d'écrire une grosse application en tcl (que nous saurions pas interprêtable) afin de la ramener par un convertisseur adéquat dans un langage compilable dans le but de la traduire. Cependant, comme le code n'a pas été analysé, il se peut que des erreurs malcontreuses viennent s'y glisser. C'est pourquoi, il est nécessaire de compartimenter un programme avec des fichiers à importer avec la commande source en tcl afin de le faire fonctionner par petit bout avant de le ramener en une seule application. Ainsi, l'application désirée aura été fractionnée par pièces (à regrouper par la suite). Voilà pour la pratique.


A+

Salut
tout faire dans une grosse application en TCL est pour moi une aberration. mais on peut très bien écrire une grosse application avec du TCL sans tout faire exploser. comme tu le fais justement remarquer TCL SAIT nativement embarquer du code compilé donc une première approche est d'écrire les bibliotèque fonctionnelles de l'application en C C++ Pascal Ada assembleur si tu veux. ensuite avec TCL tu assure la liaison entre toutes ses fonctions
Le coeur du traitement étant compilé tu as les perfs recherché et la liaison étant interprété tu as la souplesse qu'apporte de tel language au niveau de la cinématique de ton application.

une précision tout de même dans un langage interprété TOUT n'est pas en mémoire en même temp le code est lu parsé et interprété au fur et à mesure. de même lorsqu'un objet n'est plus utilisé la mémoire est libérée tout comme dans un langage compilé. mieux même car si tu oublit de le libéré l'interprète le fait pour toi. en C si tu alloue de l'espace il te faut impérativement le restituer ou tu vas droit dans le mur.

je ne connais aucun interprète de langage quel qu'il soit qui garde en mémoire toutes les instructions exécutées. au pire il garde des références sur les portion de code à réinterprété au mieux il mets en cache le code compilé.

enfin tcl n'est pas un langage interprété comme les autres car en fait il ne fait dans l'interprète que bien peu de chose. la majorité du code est compilé
l'appel d'une commande tcl en TCL se résume à lire le source reconnaître le token aller dans la table des références des commande et appeler le code compiler correspondant si le code de la dite commande n'est pas charger c'est exactement la même chose que d'appeler une fonction dune DLL qui n'est pas en memoire.
l'appel d'une fonction c'est exactement pareil
lecture du code reconnaissance du token recherche de la références et exécution de la fonction. si la fonction n'a jamais été chargé tcl ouvre le source est l'analyse. sinon il utilise le code compilé qu'il à mis en cache.
tcl n'interprète finalement que peu de chose.

mais il y a une autre façon d'utiliser TCL
c'est d'écrire une grosse appli compilée et de lui embarquer un interprète qui va permettre à l'application de bénéficier d'un langage de macro (WinCVS utilisait cette approche)

A+JYT

[habilité]

Salut.

Merci beaucoup Sekaijin pour ces précisions fortes utiles.

A+