TkBuilder pour Tcl 8.5 ?
Jibal
J'utilise TkBuilder depuis un peu plus d'un an dans des projets
professionnels ou privés et j'en suis très satisfait.
Car:
- Il est très facile à utiliser,
- Il génère un code Tcl pur et propre (sans avoir à requérir un
package spécial ou des appels à des procédures particulières) qui peut
donc être utilisé tel quel avec des outils comme Freewrap ou autres,
- Il est également très souple et permet facilement l'intégration de
packages comme les widgets Tiles ou Expect (j'ai testé !),
- Il est stable avec très peu de plantage,
- Il est gratuit,
- Sa dernière version est disponible en Français...
J'ai testé au cours de cette dernière année un large échantillon de
générateurs d'interface/RAD Tcl-Tk comme Visual Tcl, TkProe, SpecTcl/
GUI Builder et autres et je suis toujours revenu à mon bon vieux
TkBuilder pour les avantages évoqués ci-dessus.
Le seul soucis est que la dernière version de TkBuilder ne semble pas
bien compatible avec Tcl 8.5 et je me retrouve donc "coincé" en 8.4
pour le moment.
C'est pourquoi, n'étant pas suffisamment bon en Tcl moi-même pour
effectuer cette migration de TkBuilder en Tcl 8.5 (avec,
éventuellement, quelques améliorations toujours bonnes à prendre), je
fais appel à la communauté d'experts que vous êtes pour savoir si l'un
(ou plusieurs) d'entre vous pourrait y jeter un œil.
A priori, d'après ce que j'ai pu en voir, cela ne devrait pas être
insurmontable pour quelqu'un d'un peu expérimenté...
La dernière version (TkBuilder for 8.4) est disponible ici =>
http://sourceforge.net/projects/tkbuilder84/files/ avec les sources
tcl.
J'ai bien évidemment envoyé un message spécifiant la même requête sur
le forum sourceforge correspondant mais le projet semble bien endormi,
voire peut être mort...
C'est pourquoi je me permets d'envoyer cette "bouteille à la mer" en
étant quasiment sur que je ne serais pas le seul intéressé par ce
portage.
Avec mes remerciements anticipés.
Jibal.
Jibal
TkBuilder:
http://img8.imageshack.us/img8/4664/tkbuilderscreenshot1.jpg
http://img443.imageshack.us/img443/1940/tkbuilderscreenshot2.jpg
Kroc
--
David Zolli
Jibal
Non, pas tant que çà: A l'usage, on s'y retrouve très facilement...
Bien mieux en tous cas que dans un source d'un millier de lignes ou
plus.
Essayes-le et tu verras.
Proust Michel
j'ai essay� avec eTcl 8.5 et pout l'instant pas de PB
si vous pouviez pr�ciser les incompatibilit�s constat�es
bonne journ�e
"Jibal" <jba...@gmail.com> a �crit dans le message de news:
3a3c66d3-1b20-440b...@j24g2000yqa.googlegroups.com...
Juste deux copies d'�cran pour donner une id�e de ce � quoi ressemble
Kroc
> .../... A l'usage, on s'y retrouve très facilement...
> Bien mieux en tous cas que dans un source d'un millier de lignes ou
> plus.
> Essayes-le et tu verras.
Etant partisan (acharné) de l'architecture trois tiers, je m'y
retrouve très bien dans mes codes (de plusieurs dizaines de milliers
de lignes) avec un simple éditeur de texte (comme TextMate). Il n'y a
donc aucune chance que j'utilise un jour ce genre d'outil, même si
j'arrive à comprendre qu'on puisse apprécier.
--
David Zolli
Master ZU
On 6 déc, 22:42, Kroc <k...@kroc.tk> wrote:
> Etant partisan (acharné) de l'architecture trois tiers, [...]
Pour ne pas mourir idiot, qu'est ce donc l'architecture trois tiers ?
>
> --
> David Zolli
Patrick Cao Huu Thien
Kroc
> Pour ne pas mourir idiot, qu'est ce donc l'architecture trois tiers ?
C'est expliqué ici : http://wfr.tcl.tk/1655
--
David Zolli
Thomas MENEZ
> tcl.
> J'ai bien évidemment envoyé un message spécifiant la même requête sur
> le forum sourceforge correspondant mais le projet semble bien endormi,
> voire peut être mort...
>
> C'est pourquoi je me permets d'envoyer cette "bouteille à la mer" en
> étant quasiment sur que je ne serais pas le seul intéressé par ce
> portage.
>
> Avec mes remerciements anticipés.
>
> Jibal.
Bonjour Jibal,
Aurais-tu jeté un oeil à PureTkGUI ? C'est un constructeur d'IHM en
Tcl/Tk pour Tcl/Tk. Il est en plein développement et est parfaitement
compatible avec les dernières versions de Tcl/Tk (8.5 et ttk:: par
exemple).
Cdt.
A+
Thomas MENEZ
> tcl.
> J'ai bien évidemment envoyé un message spécifiant la même requête sur
> le forum sourceforge correspondant mais le projet semble bien endormi,
> voire peut être mort...
>
> C'est pourquoi je me permets d'envoyer cette "bouteille à la mer" en
> étant quasiment sur que je ne serais pas le seul intéressé par ce
> portage.
>
> Avec mes remerciements anticipés.
>
> Jibal.
Voici un screenshot :
Kroc
l'apprentissage de ce genre de programme me semble parfaitement
inutile quand on voit la syntaxe simplissime de Tk.
C'est d'ailleurs probablement la raison pour laquelle aucun de ces
trucs n'a jamais vraiment percé pour Tk.
--
David Zolli
Thomas MENEZ
Bonsoir David,
Je suis tout-à-fait d'accord sur la syntaxe Tk qui est vraiment
sensationnelle, on peut écrire de vraies IHM en quelques lignes, et
celles-ci restent très lisibles.
Mon expérience personnelle m'a montré qu'un outil WYSIWYG permet à
certains de gagner du temps lorsqu'il s'agit de modifier une IHM
existante ou alors d'en créer une très rapidement pour du maquettage.
Ce genre d'outil peut aussi s'avérer très pertinent pour les débutants
pour voir les effets en temps réel des commandes (pack, place...) et
des options des widgets qui leurs sont d'ailleurs toutes présentées
sans avoir à les chercher dans le "man".
Ce "machin" comme tu dis est somme toute une appli Tk assez complexe
qui m'apprend bcp de chose sur Tcl/Tk, la développer est à mon sens le
meilleur moyen d'embrasser l'ensemble des spécificités de Tk. Là ou
cela devient sympathique d'un point de vue conceptuel c'est que
PureTkGUI est développé avec PureTkGUI, à l'image des compilateurs
compilés par eux-mêmes...
Pour l'instant, tout n'est pas encore supporté par PureTkGUI, donc une
partie du code 'statique', c-a-d la définition des widgets de
pureTkGUI est écrite à la main, mais au fil des versions, la quasi
totalité de la définition de l'IHM sera un simple projet PureTkGUI.
D'autre part, l'utilisation du "machin" est finalement assez simple.
Tu peux packer, gridder, placer des widgets et régler leur propriétés
comme tu le ferais à la main, donc rien de bien fantastique à
apprendre.
Le but de ces "machins" n'est pas de percer mais de faciliter le
travail qui peut être dans certains cas laborieux et ennuyeux (par
exemple renommage de widgets lors de leur déplacement). Ces "machins"
sont très usités, il suffit de regarder les stats de download sur
SourceForge...
Enfin pour finir, la génération de code est un axe majeur du
développement logiciel aujourd'hui, c'est donc dans ce cadre que
s'inscrit tout naturellement PureTkGUI. A titre de teaser, une feature
majeure à venir est la génération de code Python/TkInter, ce qui sera
relativement trivial.
Merci néanmoins pour ton témoignage qui aura permis de préciser
certains éléments.
Cordialement et bon codage Tcl :).
Thomas
Kroc
Chacun est, bien entendu, libre d'utiliser ce qu'il veut et je n'ai
fait qu'exprimer mon sentiment personnel, qui n'est pas parole
d'évangile.
Il se trouve qu'en 10 ans d'usage de Tk dans un cadre professionnel,
un fainéant dans mon genre n'a jamais eu besoin de ce genre de
programme, d'où mon énorme scepticisme.
Quoi qu'il en soit, si ton projet redonne un peu de vigueur à Tcl en
France, j'en serai très heureux et je lui souhaite beaucoup de
succès !
--
David Zolli
Eric Hassold
> Le but de ces "machins" n'est pas de percer mais de faciliter le
> travail qui peut �tre dans certains cas laborieux et ennuyeux (par
> exemple renommage de widgets lors de leur d�placement). Ces "machins"
> sont tr�s usit�s, il suffit de regarder les stats de download sur
> SourceForge...
<humour>
La, a 4:59 le 13 decembre, SF rapporte sur la page de telechargement "0
download" pour la version 0.9 publiee il y a 3 jours (et 111 en 1 mois
1/2 pour la version precedente). Peut-etre pas le meilleur argument a
mettre en avant pour justifier un "tres usites" :p
</humour>
Oui, je sais, les stats ne sont pas calculees en temps reel, et doivent
de toute facon generalement etre prises avec des pincettes sur SF. Mais
ce n'etait qu'un petit elant d'humeur taquine du samedi soir.
Plus serieusement, je dois admettre adherer plutot (bon, en fait,
totalement) aux arguments de Kroc. Les codes generes par ces outils sont
generalement verbeux, donc difficile (voire impossible) a maintenir. En
outre, de ce que j'en vois, comprendre le fonctionnement de l'outil
necessite de connaitre deja les mecanismes de Tk (choisir le widget, ses
options, si on veut utiliser pack, grid ou place, etc...), donc
faciliter le ticket d'entree pour les nouveaux venus ne me semble pas
etre un but atteint.
Mais surtout (le grand MAIS), ces outils sont calques sur les outils de
design de dialogues pour les toolkits compiles (les Visual C++ et
autres), et en suivant ce chemin, font perdre tout le benefice (majeur)
de reposer sur un langage dynamique (Tcl dans le cas de Tcl/Tk, mais la
meme chose s'applique a Python/Tkinter). Vous parlez de renommage de
wigets, mais justement, c'est un probleme de langages compiles, qui ne
se pose pas quand on dispose d'un langage dynamique. Par exemple,
j'ecris quasiment jamais des
button .view1.frame32.save -text save
button .view1.frame32.quit -text quit
mais plutot des
button $parent.save -text quit
button $parent.quit -text quit
et en mettant le tout dans une procedure, je n'ai plus qu'a passer la
valeur que je veux a l'argument $parent (ce qui, dans la foulee, me
permet de factoriser les blocs similaires de mon interface). De meme, si
la liste des widgets a afficher depend d'options choisies par
l'utilisateur, ou de parametres qui peuvent changer dans le temps, un
langage dynamique me permet de definir mon interface a la volee, par
exemple avec une construction du genre :
set btnid 0
foreach item $mesactions {
pack [button $parent.btn[incr btnid] -text .....]
}
ce que ne permettra pas un constructeur visuel. Donc, a mon sens, ce
genre d'outils a du mal a trouver sa place car l'approche n'apporte
aucune solution au debutant, tandis que le developpeur plus experimente
deplore rapidement la perte du cote dynamique, la perte de la maitrise
non seulement de son code mais egalement de son architecture (la mise en
oeuvre d'une architecture 3-tier, citee par Kroc, est un bon exemple
classique d'architecture pertinente incompatible avec ces outils visuels).
Comme pour Kroc, ceci n'a pour vocation que d'apporter mon opinion
personnelle et quelques elements de reflexion. Donc, une fois cela dit
pour le plaisir de debattre, je me rejouis de l'apparition de tout
nouveau projet Tcl qui vient enrichir notre paysage, alors longue vie a
PureTkGUI.
Eric
yann.raoul
> Le 13/12/2009 00:34, Thomas MENEZ a écrit :
>
> > Le but de ces "machins" n'est pas de percer mais de faciliter le
> > exemple renommage de widgets lors de leur déplacement). Ces "machins"
Bonjour,
Vous devez être des experts de ce langage que je trouve en effet très
pratique.
Je ne vais pas remettre en cause ce que vous dîtes,
mais juste vous signaler que ce type d'outil est bien au contraire
très utilisé.
Il ne faut pas prendre l'auteur de PureTkGui comme quelqu'un de
prétentieux (c'est ce que vous venez de faire en allant voir
uniquement les stats de son GUI Builder). Allez voir celles de Visual
Tcl par exemple.
Je peux même témoigner (travaillant chez un grand industriel de
l'aéronautique) que Visual Tcl a souvent été utilisé dans ce
secteur.
En résumé, je peux partager votre avis de puriste,
mais selon moi, ce type d'outils fait vivre ce langage
Cordialement
Yann
Kroc
> Il ne faut pas prendre l'auteur de PureTkGui comme quelqu'un de
> prétentieux (c'est ce que vous venez de faire en allant voir
> uniquement les stats de son GUI Builder). Allez voir celles de Visual
> Tcl par exemple.
Ni moi ni Éric n'avons porté le moindre jugement sur Thomas, Éric a
même pris la peine de bien mettre des balises <humour> autour de sa
remarque pour éviter toute méprise.
Quant au succès de Visual Tcl : il est tout à fait relatif (5% du
volume de téléchargement de Tcl sur SF, c'est à dire sans compter la
majeure partie de la distribution de Tcl : ActiveTcl, eTcl et les
versions pré-installées avec l'OS (Mac et Linux).
Après, ce n'est pas une question d'être puriste ou pas, mais comme l'a
très bien expliqué Éric, les constructeurs d'interface ne permettent
pas d'utiliser les méthodes typiques des langages de script avec le
parent passé en paramètre d'une procédure, dans une architecture trois
tiers stricte.
On est tous d'accord sur un point : ces outils peuvent attirer du
monde vers Tcl et ça c'est très bien !
--
David Zolli
Eric Hassold
Le 13/12/2009 12:17, yann.raoul a �crit :
> Bonjour,
>
> Vous devez �tre des experts de ce langage que je trouve en effet tr�s
> pratique.
> Je ne vais pas remettre en cause ce que vous d�tes,
> mais juste vous signaler que ce type d'outil est bien au contraire
> tr�s utilis�.
> Il ne faut pas prendre l'auteur de PureTkGui comme quelqu'un de
> pr�tentieux (c'est ce que vous venez de faire en allant voir
> uniquement les stats de son GUI Builder). Allez voir celles de Visual
> Tcl par exemple.
Vous me pretez un jugement que ne j'ai jamais eu. J'ai trouve
humouristique de mettre en avant les stats SF, alors que ces stats
etaient a 0. Et conscient qu'un clin d'oeil peut etre ambigu par ecrit
sur usenet, j'ai pris la peine de preciser excplicitement qu'il ne
s'agissait que d'un trait d'humour, mais meme cela ne suffit pas
manifestement. Desole si ce gout pour l'ironie est mal interprete.
> Je peux m�me t�moigner (travaillant chez un grand industriel de
> l'a�ronautique) que Visual Tcl a souvent �t� utilis� dans ce
> secteur.
Quant au reste du message, le but n'a jamais ete de demontrer que ces
outils ne sont pas utilises, et encore moins qu'ils ne meritent pas
d'exister. VisualTcl et l'excellent TkGUIBuilder (derive de SpecTcl, et
dont les sources ont ete gracieusement ouvertes par ActiveState) sont de
tels outils populaires, dont je me rejouis de l'existence (comme je me
rejouis de celle de PureTkGUI, comme je l'ai ecrit dans mon post) et
qui, bien sur, repondent a une demande. Mais cela n'empeche pas de
debattre et de donner son opinion, tres respectueusement. J'aurais pu
avancer plusieurs de ces arguments sur un debat similaire entre editeur
graphique HTML vs. editer son html, ses CSS et son javascript, ou encore
de la pertinence d'utiliser QtDesigner pour definir son interface
graphique par dessus Qt. Le seul but etait de mettre en avant l'avantage
de la nature dynamique de Tcl, et pourquoi cette caracteristique
essentielle peut influer sur la pertinence d'adopter ou pas un editeur
visuel. Si quoi que ce soit dans mes propos ressemble a du denigrement
du travail de qui que ce soit, ou peut laisser croire que je suis contre
le pluralisme, ca ne reflete pas ce que je pense et m'en excuse.
> En r�sum�, je peux partager votre avis de puriste,
> mais selon moi, ce type d'outils fait vivre ce langage
Simple copier/coller de mon message precedent, qui va bien dans ce sens:
Miko
Parfait ignare, j'ai d�but� la programmation avec Delphi, et pour situer mon
niveau, � l'�poque je faisais difficilement la diff�rence entre une variable
locale et une variable globale. N�anmoins, cet outil, on ne peut plus
visuel, m'a permis de faire fonctionner (apr�s bien des d�boires, vous vous
en doutez...) mes premiers programmes.
J'ai d�couvert Tcl/Tk avec Visual Tcl, qui �tait pr�install� sur une
Slackware, et peu � peu, j'ai appris quelques m�canismes, qui m'ont permis
d'avancer un peu plus loin.
Ma curiosit� naturelle a fait le reste, et aujourd'hui, je code toujours
comme un cochon, mais enti�rement � la main, enfin, je veux dire avec un
simple �diteur de code.
Tout ceci pour dire que je pense qu'un g�n�rateur d'interface peut aider le
d�butant � s'interesser � un langage, quelqu'il soit, donc que Thomas a eu
une bonne id�e, m�me si je ne pense pas utiliser son outil.
Je dois �galement avouer que la majeure partie de mon utilisation
professionnelle de Tcl/tk repose sur Tcl tout seul...
Miko
Vincent Verdon
je crois que tu as �t� un peu vex� de la remarque de David. Venant de sa
part, je peux affirmer que ce n'�tait pas voulu.
Quand � la promotion d'un gui pour Tc/Tk, je pense qu'effectivement, ce
peut �tre bien pour approcher notre merveilleux langage, mais il est
vrai que d�s que l'on doit gratter un peu dans le code, cela devient
vite moche. Personnellement, j'ai d�couvert Tcl/Tk gr�ce � un article
dans un des premiers Linux Magasine, et j'ai �t� s�duit par la facilit�
d'�criture du code. A cette �poque, j'avais arr�t� de programmer depuis
ma sortie de fac, 10 ans auparavant. Je dis toujours, que sans la
d�couverte de Tcl/Tk, je n'aurais jamais recommenc� � programmer. J'ai
ensuite test� Visual Tcl, et j'ai vite compris que ce n'�tait pas tr�s
pratique, m�me si cela semblait all�chant au premier abord. J'ai trouv�
qu'�crire le code enti�rement � la main est bien plus agr�able, finalement.
Mais tout de m�me j'ai r�v� un moment de d�velopper une modeste
application de cr�ation d'interface : le but �tant de cr�er simplement
une toplevel avec son contenu, sans en faire une application compl�te de
d�veloppement. J'avais pens� d'ailleurs � pr�voir l'aspect dynamique
dont parle Eric un peu plus loin.
Je n'en ai pas trouv� le temps...
En conclusion, je pense que tout outil permettant de faire d�couvrir et
utiliser Tcl/Tk est bon ! Ensuite � chacun de se faire son opinion.
Car ce qui reste vrai, c'est que Tcl/Tk est fort mal connu, tout du
moins dans notre pays : j'essaie pourtant d'en faire la promotion, mais
sans grand r�sultat jusqu'� pr�sent !
Amicalement, Vincent Verdon
Thomas MENEZ
Non, je n'ai pas été vexé par vos propos. Je voudrais toutefois tenter
de répondre aux interrogations soulevées ici ou là :
On Dec 13, 5:16 am, Eric Hassold <hass...@evolane.com> wrote:
> Les codes generes par ces outils sont
> generalement verbeux, donc difficile (voire impossible) a maintenir.
C'est effet une tendance générale de la génération de code qui adresse
souvent une multitude de cas, rendant le code complexe par rapport à
ce que l'on aurait pu écrire à la main à tâche équivalente. Il s'en
suit une double difficulté, celle de comprendre/debugger le code
généré, et celle de le faire évoluer. Le principal argument opposé,
et qui est quand même assez facilement recevable, est qu'on n'a
pas à mettre le "nez dedans" car le générateur de code est considéré
validé, et que si un problème s'y trouve, c'est que le paramétrage
choisi par l' utilisateur est quelque peu inapproprié. L'utilisateur
est donc prié de vérifier son paramétrage.
Toutefois, l'étude du code généré peut s'avérer utile en phase d'ap-
prentissage, où l'on a reussi à paramétrer une IHM, générer le code et
exécuter cette IHM qui nous satisfait. On est alors souvent tenté de
regarder sous le capot pour comprendre comment tout ceci se code.
PureTkGUI propose deux options afin de lutter contre la verbosité
excessive de certains générateurs de code, et d'améliorer la lisi-
bilité du code généré :
1) Une option, et c'est primordial, qui limite la génération de
code aux valeurs réellement choisies par l'utilisateur au
niveau de la configuration de ses widgets. Autrement dit les
valeurs par défaut des options ne sont pas générées.
Note : fonction présente dans l'IHM de la v0.9.0 mais
non encore activable.
2) Plusieurs options de mise en forme du code généré permettant à
l'utilisateur de privilégier un formatage particulier du code
généré.
Note : idem
> En outre, de ce que j'en vois, comprendre le fonctionnement de l'outil
> necessite de connaitre deja les mecanismes de Tk (choisir le widget, ses
> options, si on veut utiliser pack, grid ou place, etc...), donc
> faciliter le ticket d'entree pour les nouveaux venus ne me semble pas
> etre un but atteint.
C'est à demi-vrai. Un parfait débutant qui joue avec un GUI builder va
essayer un peu toutes les fonctionnalités en aveugle, et essayer de
comprendre les conséquences de ses actions. Ce sera bcp plus rapide
que de les tester en codant au "hasard", après avoir lu en diagonale
les docs (aspect rebarbartif souvent négligé).
> Mais surtout (le grand MAIS), ces outils sont calques sur les outils de
> design de dialogues pour les toolkits compiles (les Visual C++ et
> autres), et en suivant ce chemin, font perdre tout le benefice (majeur)
> de reposer sur un langage dynamique (Tcl dans le cas de Tcl/Tk, mais la
> meme chose s'applique a Python/Tkinter).
Et c'est ici que naît la 1ere incompréhension du but de l'outil Pure-
TkGUI. Le but de PureTkGUI n'est pas d'offir un full IDE Tcl/Tk, c'est
-à-dire une IHM 'PureTkGUI' en remplacement définitif du bon vieil
éditeur de code. Au contraire, le but de PureTkGUI est d'offrir un
compagnon à l'éditeur, en laissant le soin à PureTkGUI de s'occuper
des tâches bassement répétitives, inintéressantes, peu gourmandes en
neurones et ennuyeuses à coder (!) : le côté purement statique d'une
IHM. Les widgets utilisés, leur taille, position, etc... Le code ma-
nuel se contentera alors d'animer cette IHM, et de la faire vivre gâce
à son aspect dynamique que vous évoquez, tâche que tcl remplit très
bien. Je donne un exemple plus loin des moyens mis en oeuvre pour
atteindre cet objectif. En résumé, un fichier (ou plusieurs si besoin)
généré par PureTkGUI pour les aspects statiques, un jeu de fichiers
écrits à la main pour les aspects dynamiques. Cette approche
conservatrice se prête très bien à l'archi 3 tiers que vous décrivez
et qui me semble bien adaptée.
L'interactivité améliorée (au sens productivité améliorée) :
Visual C++ et cie n'ont pas inventé grand chose dans la conception d'
IHM. Malheureusement, dans la vraie vie du travail on nous en demande
toujours plus, plus rapide, plus efficace. Ce qu'essaye d'apporter un
outil comme PureTkGUI ou autre est une interactivité améliorée pour
gagner du temps.
Exemple concret: j'utilise le placer (OK c'est criticable, mais
admettons ce use case) : si je le code à la main, combien de fois
vais-je devoir modifier le code / sauver le fichier / lancher le wish
monFic.tcl / attendre que l'appli se lance / aller au bon endroit dans
l'IHM pour constater que l'on n'est pas bien placé à 3 pixels près ?
Alors qu'un simple cliquer déplacer d'un widget dans une IHM se fait
en qqs seconde ? Il n'y a même pas de débat (et ne restent que les
obstinés idéologiques ou les gâtés de temps libre). Ce raisonnement
peut assez facilement se généraliser aux autres use cases composant
la création d'une IHM.
> Vous parlez de renommage de
> wigets, mais justement, c'est un probleme de langages compiles, qui ne
> se pose pas quand on dispose d'un langage dynamique. Par exemple,
> j'ecris quasiment jamais des
>
> button .view1.frame32.save -text save
> button .view1.frame32.quit -text quit
>
> mais plutot des
>
> button $parent.save -text quit
> button $parent.quit -text quit
>
> et en mettant le tout dans une procedure, je n'ai plus qu'a passer la
> valeur que je veux a l'argument $parent (ce qui, dans la foulee, me
> permet de factoriser les blocs similaires de mon interface).
Nota : générer des IHM à la volée n'est pas forcément recommandé pour
de betes aspects de performances. Il est fortement recommandé de créer
toutes les IHMs à l'init (sauf celles qui seront forcément changeantes
en fonction du contexte). Il est tout à fait possible de factoriser
le code d'init de la meme maniere. Mais nos quad coeurs modernes nous
font oublier ces principes élementaires du codage efficace ;).
Effectivement, j'ai moi-même aussi utilisé cette technique assez répan
due(même utilisée par visual tcl dans son code généré).Elle remplit le
besoin que tu énonces mais cette technique fait passer au codeur
tropde temps à quelquechose qui ne devrait pas prendre de temps(aucune
valeur ajoutée dans ce code).Il faut que tu créées ta variable parent,
que tu la gères etc... Le mécanisme que propose PureTkGUI pour éviter
cet ecueil de nommage et pour s'affranchir plus globalement de la
stratégie de nommage des widgets, c'est de les nommer bêtement et d'ou
blier le nom des widgets. Dans PureTkGUI, les widgets sont nommés par
des entiers. .0, .1, .2, ... .n. 0.1, 0.2, 0.1.1, etc... Des noms
parfaitement inexploitables mais que l'on ne souhaite pas exploiter,
donc tout va bien. Il est tout de meme possible dans PureTkGUI de choi
sir son nom de widget .maFrame, etc... si on ne veut pas de nommage au
to "bête", mais bon. Comment manipuler les widgets alors ? Le
constat
que j'ai fait estqu'en réalité dans une IHM,on n'a besoin de manipuler
(et faire vivre)qu'un nombre restreints de widgets. On a bcp de frames
de labels, qui sont parfaitement statiques durant toute la vie de l'ap
plication. Les autres, ceux qui nous interessent, on veut pouvoir les
manipuler. Dans PureTkGUI, c'est fait via des alias (mais si on le
souhaite, encore une fois, on peut nommer ses widgets à l'ancienne).
Chaque widget auquel on veut accéder dans notre bon vieil éditeur est
accessible via son alias.
Exemple : un button .1.5.7.1.5.6 aura un alias 'but_validateUsersForm'
On y accèdera dans le code
par :
$::myWidgets(but_validateUsersForm). myWidgets étant
un tableau généré par PureTkGUI, le nom étant paramé-
trable pour plus de souplesse.
On y gagne sur le plan de la lisibilité et surtout sur la maintena-
bilité du code écrit à la main (ce qui est cent fois plus important
que la maintenabilité du code généré évoquée + haut). Il sera possible
de complètement chambouler la position du bouton dans l'IHM, on n'aura
pas à toucher une ligne du code géré à la main (même pas à changer la
valeur de parent ;) ).
> De meme, si
> la liste des widgets a afficher depend d'options choisies par
> l'utilisateur, ou de parametres qui peuvent changer dans le temps, un
> langage dynamique me permet de definir mon interface a la volee, par
> exemple avec une construction du genre :
>
> set btnid 0
> foreach item $mesactions {
> pack [button $parent.btn[incr btnid] -text .....]
>
> }
>
> ce que ne permettra pas un constructeur visuel.
Dans la bonne vision des choses, le constructeur visuel te permettrade
construire tout le reste et ton code à la main se chargera de faire le
code que tu décris. Ton code manuel deviendrait :
set btnid 0
foreach item $mesactions {
pack [button $::myWidgets(frm_MotherDesButtons).btn[incr btnid] -
text
}
et il serait insensible aux variations d'IHM...
> Donc, a mon sens, ce
> genre d'outils a du mal a trouver sa place car l'approche n'apporte
> aucune solution au debutant,
Je pense que si, via un apprentissage en "aveugle", cf. + haut. Je
pense aussi betement à la personne qui a besoin de faire une IHM etqui
n'a aucune connaissance particuliere en termes de langage... S'il peut
jouer un peu avec un truc qui lui fait des boutons, etc... sans avoir
a pondre, c'est un bon moyen de lui faire découvrir la puissance de
tcl/tk. Très peu de chance qu'il se tape un tutorial Tcl/Tk, le man
etc... Il veut aller vite et avoir un resultat visuel, ne serait-ce
qu'une ebauche, assez rapidement (sans avoir à potasser : potasser
oui quand on mettra au point / ameliorera le truc).
> tandis que le developpeur plus experimente
> deplore rapidement la perte du cote dynamique, la perte de la maitrise
> non seulement de son code mais egalement de son architecture (la mise en
> oeuvre d'une architecture 3-tier, citee par Kroc, est un bon exemple
> classique d'architecture pertinente incompatible avec ces outils visuels).
"Sans maîtrise la puissance n'est rien" ;). En fait il faut savoir
comment exploiter ces outils et ne pas tomber dans le piege du full
IDE... qui n'a pas d'intérêt avec Tcl/Tk, sur ce point nous sommes
parfaitement en phase. "PureTkGUI : 3 tier compatible ! ;-)"
> Comme pour Kroc, ceci n'a pour vocation que d'apporter mon opinion
> personnelle et quelques elements de reflexion. Donc, une fois cela dit
> pour le plaisir de debattre, je me rejouis de l'apparition de tout
> nouveau projet Tcl qui vient enrichir notre paysage, alors longue vie a
> PureTkGUI.
>
> Eric
Merci pour tes voeux !
Kroc
> .../... Le principal argument opposé,
> et qui est quand même assez facilement recevable, est qu'on n'a
> pas à mettre le "nez dedans" car le générateur de code est considéré
> validé, et que si un problème s'y trouve, c'est que le paramétrage
> choisi par l' utilisateur est quelque peu inapproprié. L'utilisateur
> est donc prié de vérifier son paramétrage.
Ce qui sous-entend que tous les participants au développement
utilisent PureTkGUI, ce qui ajoute une contrainte déplaisante à la
gestion d'un projet.
> .../...
> Nota : générer des IHM à la volée n'est pas forcément recommandé pour
> de betes aspects de performances. Il est fortement recommandé de créer
> toutes les IHMs à l'init (sauf celles qui seront forcément changeantes
> en fonction du contexte). Il est tout à fait possible de factoriser
> le code d'init de la meme maniere. Mais nos quad coeurs modernes nous
> font oublier ces principes élementaires du codage efficace ;).
Une bonne partie de ma production tourne sur PDA (WinCE ou linux) avec
des petits processeurs (même chose pour Éric) et je ne suis pas
d'accord avec toi :
1) "à la volée" s'applique au nom du widget selon son contexte, pas à
l'instant de sa création.
2) sur un PDA, on économise avant tout la mémoire et le temps
processeur : on ne construit un widget que s'il est appelé au moins
une fois, la première fois qu'il est appelé. Tout construire au début
prendrait trop de temps sur ces petites bêtes. ;^)
> .../...
> Chaque widget auquel on veut accéder dans notre bon vieil éditeur est
> accessible via son alias.
>
> Exemple : un button .1.5.7.1.5.6 aura un alias 'but_validateUsersForm'
> On y accèdera dans le code par : $::myWidgets(but_validateUsersForm)
On revient à ce que je fais à la main, sauf que dans mes codes, c'est
ma procédure qui retourne mon nom de widget en fin de création.
> .../... Je pense
> aussi betement à la personne qui a besoin de faire une IHM et qui
> n'a aucune connaissance particuliere en termes de langage... S'il peut
> jouer un peu avec un truc qui lui fait des boutons, etc... sans avoir
> a pondre, c'est un bon moyen de lui faire découvrir la puissance de
> tcl/tk. Très peu de chance qu'il se tape un tutorial Tcl/Tk, le man
> etc... Il veut aller vite et avoir un resultat visuel, ne serait-ce
> qu'une ebauche, assez rapidement (sans avoir à potasser : potasser
> oui quand on mettra au point / ameliorera le truc).
C'est vrai, la tendance à la fainéantise généralisée rend ce genre
d'outil attractif. Je suis d'accord avec toi qu'il sera probablement
très utilisé par les gens qui codent peu ou occasionnellement en Tk ou
ceux qui souhaitent découvrir le langage (à l'instar du parcours de
Miko).
Cependant, je reste convaincu que ce type d'outil n'est pas du tout
adapté en production. Ton outil produit un code trop spécifique qui
serait extrêmement pénalisant à maintenir à la main si un jour
PureTkGUI venait à disparaître (ce qui est plus ou moins arrivé à tous
les précédents GUI builders pour Tk).
Mon expérience de la gestion de projets m'a montré que plus simple et
standard est la toolchain et mieux on se porte !
--
David Zolli
Thomas MENEZ
Bonjour Kroc
> Ce qui sous-entend que tous les participants au développement
> utilisent PureTkGUI, ce qui ajoute une contrainte déplaisante à la
> gestion d'un projet.
L'utilisation d'outils communs au sein d'une même équipe déve-
loppant du soft est fondamental. Je ne pense pas être le seul
à le dire...
> Cependant, je reste convaincu que ce type d'outil n'est pas du tout
> adapté en production. Ton outil produit un code trop spécifique qui
> serait extrêmement pénalisant à maintenir à la main si un jour
> PureTkGUI venait à disparaître (ce qui est plus ou moins arrivé à tous
> les précédents GUI builders pour Tk).
La disparition d'un outil open source est relative... Les sources
sont dispos et donc l'outil ne meurt pas vraiment. Si un bug
tres genant est mis en évidence, il peut être corrigé. La qualité
du code source de l'outil peut alors devenir un critère intéressant
à cet égard.
Une reprise à la main n'a donc pas vraiment de sens car l'outil
ne disparaitra pas... Ceci étant, le code généré à ce jour n'est
certainement pas parfait.Tu parles de "trop spécifique". Comment
pourrais-je améliorer la situation à ton avis? J'ai déjà qques idées,
mais je suis ouvert à toute suggestion :-).
>
> Mon expérience de la gestion de projets m'a montré que plus simple et
> standard est la toolchain et mieux on se porte !
Dans une certaine mesure c'est vrai, mais simplifier les choses
à l'extrême peut te faire passer à côté d'outils intéressants. A
chacun de trouver son bonheur !!
> --
> David Zolli
Thomas Ménez
Jibal
> Bonjour Jibal,
>
> Aurais-tu jeté un oeil à PureTkGUI ? C'est un constructeur d'IHM en
> Tcl/Tk pour Tcl/Tk. Il est en plein développement et est parfaitement
> compatible avec les dernières versions de Tcl/Tk (8.5 et ttk:: par
> exemple).
>
> Cdt.
> A+
Oui, je viens de tomber dessus et je vous ai justement posté une
question sur votre forum SF.
Je fonde beaucoup d'espoir dans votre travail sur PureTkGui car, comme
je le disais, je suis actuellement coincé avec ce vieux TkBuilder en
8.4 et j'aimerais moi aussi pouvoir profiter des nouveautés des
nouvelles versions de Tcl.
Je ne suis pas, quant à moi, un "puriste" de Tcl au point de ne
pouvoir envisager de programmer autrement qu'avec un banal éditeur de
texte:
Si un outil me permet de gagner du temps, de générer du code
relativement propre et de pouvoir aisément faire évoluer mes
programmes, çà me va.
C'est ce qu'à accompli TkBuilder pour moi ces trois dernières années
et si PureTkGui y parvient également, cela m'ira très bien également.
Un ami, également vieil utilisateur de TkBuilder, l'a installé tout à
l'heure sur un Tcl 8.6 et m'a dit qu'en l'état actuel des choses,
PureTkGUI était encore un peu "vert", ce qui est normal vu la jeunesse
du produit.
Je vais donc attendre la version 1 avant d'upgrader mon ActiveTcl en
8.5 ou 8.6...
Quoiqu'il en soit, je soutiens pleinement votre initiative et je vous
encourage chaudement dans vos efforts.
Jibal
Bon, ben, très bien, ne l'essaye pas alors...Que dire de plus ?
Cependant, si c'est pour toi une règle d'airain, je ne comprends pas
trop ce qui te motive à agonir de tant de critiques plus ou moins
constructives des outils...Dont tu ne te serviras de tout façon
jamais !
Eric Hassold
> je ne comprends pas trop ce qui te motive � agonir de tant de critiques plus ou moins
> constructives des outils...Dont tu ne te serviras de tout fa�on jamais !
J'ai un doute, verifions...
agonir: (verbe transitif)
Accabler d'injures, insulter.
Ah ben oui, c'est tout David, ca, toujours a insulter et jamais a rendre
service de facon constructive!
Bon, perso, je relis et relis son message a la recherche, parmi "tant de
critiques", d'au moins une qui me sauterait au yeux. Mais n'y vois que
des opinions personnelles, exprimees avec respects, et qui alimentent la
discussion au sein d'un groupe de discussion (ce qui semble assez
coherent jusqu'a la :p). Bah, je dois passer a cote de l'essentiel.
Eric
Vincent Verdon
Jibal a �crit :
>
> Je fonde beaucoup d'espoir dans votre travail sur PureTkGui car, comme
> je le disais, je suis actuellement coinc� avec ce vieux TkBuilder en
> 8.4 et j'aimerais moi aussi pouvoir profiter des nouveaut�s des
> nouvelles versions de Tcl.
> Je ne suis pas, quant � moi, un "puriste" de Tcl au point de ne
> pouvoir envisager de programmer autrement qu'avec un banal �diteur de
> texte:
>
J'ai l'impression que tu penses �tre tomb� sur un forum hant� par des
personnes obtues qui ne jurent que par une forme de programmation disons
"peu accessible". Le mot que tu emploie : "puriste" ainsi que ta
r�action au message de Kroc un peu plus haut me le font croire.
Alors je veux juste te dire que tu te trompes, que ce forum a toujours
�t� tr�s ouvert, � tous, � toutes les fa�on de voir, qu'il est fr�quent�
par des gens particuli�rement serviables et compr�hensifs.
Sur le fond, Kroc te donne juste son avis de professionnel et je suis
bien s�r qu'il est ravi de pouvoir �changer avec toi !
Amicalement, Vincent Verdon
Kroc
> Sur le fond, Kroc te donne juste son avis de professionnel et je suis
> bien sûr qu'il est ravi de pouvoir échanger avec toi !
Tout à fait ! Je ne me suis exprimé que par rapport à mes propres
besoins, pas par rapport à la qualité intrinsèque du produit.
Quand je déclare ne pas aimer utiliser ce genre d'outil, ce n'est pas
une question de purisme (ou de snobisme) mais c'est juste que j'aime
avoir la pleine maîtrise du code que je génère. Laisser un outil
écrire du code à ma place m'inquiète plus qu'il ne me fait gagner du
temps.
En fait, je suis un peu comme un vieux pilote de rallye qui ne veut
pas d'ESP sur sa voiture.
Vous remarquerez d'ailleurs que j'ai donné le Youpi de bronze 2009 à
Thomas Menez pour PureTkGUI 0.9.0 ;^)
--
David Zolli
Kroc
> Bon, ben, très bien, ne l'essaye pas alors... Que dire de plus ?
Si, je l'ai justement essayé, parce que je ne parle jamais de ce que
je n'essaye pas.
> Cependant, si c'est pour toi une règle d'airain, je ne comprends pas
> trop ce qui te motive à agonir de tant de critiques plus ou moins
> constructives des outils... Dont tu ne te serviras de tout façon
> jamais !
Tes propos sont très exagérés par rapport à mes remarques sur ces
outils. En effet, mes critiques étaient argumentés, donc
constructives. Je n'ai jamais été insultant (je pense même que tu peux
reprendre mes 1324 messages sur fclt sans trouver la moindre insulte).
Quant à ce qui me motive ? Comme toujours : promouvoir Tcl, aider à
l'améliorer, aider les utilisateurs potentiels à choisir en toute
connaissance de cause.
J'en veux pour preuve que le 17 Décembre dernier, en dépit de mes
critiques ici sur PureTkGUI, je lui ai accordé un Youpi de bronze :
http://wfr.tcl.tk/Youpi distinction courue s'il en est !
Quoi qu'il en soit, Jibal, la controverse étant ce qui fait avancer la
connaissance, continue de donner ton avis passionné ici où nous
manquons cruellement de passion ces derniers temps. Modère juste un
peu plus tes propos pour ne pas vexer les gens plus susceptibles que
moi. ;^)
--
David Zolli
Kroc
> Ah ben oui, c'est tout David, ca, toujours a insulter et jamais a rendre
> service de facon constructive!
Oui hein, quel pénible je fais ! ;^)
--
David Zolli
MSEdit
A propos des outils qui génère du code, j'ai utilisé la semaine
dernière fickle/taccle (pour parser des formules dans une langage
proche du C) qui ont généré du code TCL pour Moi, Je suis TRES content
de ne pas avoir a coder ça a la main en TCL.
Tu vois David !
Perso, je préfère coder mes interfaces a la main, en plus je suis
'sado' je n'utilise presque uniquement 'pack' !
Martyn
Jibal
>
> > je ne comprends pas trop ce qui te motive à agonir de tant de critiques plus ou moins
> > constructives des outils...Dont tu ne te serviras de tout façon jamais !
>
> J'ai un doute, verifions...
>
> agonir: (verbe transitif)
> Accabler d'injures, insulter.
>
> Ah ben oui, c'est tout David, ca, toujours a insulter et jamais a rendre
> service de facon constructive!
>
> Bon, perso, je relis et relis son message a la recherche, parmi "tant de
> critiques", d'au moins une qui me sauterait au yeux. Mais n'y vois que
> des opinions personnelles, exprimees avec respects, et qui alimentent la
> discussion au sein d'un groupe de discussion (ce qui semble assez
> coherent jusqu'a la :p). Bah, je dois passer a cote de l'essentiel.
>
> Eric
Effectivement, je reconnais avoir été excessif sur ce coup-là et je
présente donc mes excuses à David pour ce message peu amène.
Car, j'avais déjà reçu dans le passé ce genre d'avis un peu
péremptoire concernant un autre "GUI Builder": Visual Tcl
...Bon, d'accord, il se trouve que pour ce cas particulier, David
avait effectivement 100% raison, comme j'ai pu le constater amèrement
par la suite ! 8-(.
Cependant, quelques soient les travers de ce type d'outils, ils
peuvent se révéler parfois d'une grande aide pour ceux qui, comme moi,
sont loin d'avoir une connaissance aussi approfondie du langage que
David.
Enfin, j'avoue que sa première réponse ((je cite: "Et bien ! Tu parles
d'une interface compliquée !" ) à mon post initial et origine de ce
fil , m'a semblée, comment dire...Un peu décalée par rapport à ce
qu'humblement j'attendais.
Mais ce ne sont guère là que mes opinions personnelles que je tenterai
désormais d'exprimer avec respect...
Jibal
> On 12 jan, 16:08, Jibal <jbal...@gmail.com> wrote:
>
> > Bon, ben, très bien, ne l'essaye pas alors... Que dire de plus ?
>
> Si, je l'ai justement essayé, parce que je ne parle jamais de ce que
> je n'essaye pas.
>
> > Cependant, si c'est pour toi une règle d'airain, je ne comprends pas
> > trop ce qui te motive à agonir de tant de critiques plus ou moins
> > constructives des outils... Dont tu ne te serviras de tout façon
> > jamais !
>
> Tes propos sont très exagérés par rapport à mes remarques sur ces
> outils. En effet, mes critiques étaient argumentés, donc
> constructives. Je n'ai jamais été insultant (je pense même que tu peux
> reprendre mes 1324 messages sur fclt sans trouver la moindre insulte).
>
> Quant à ce qui me motive ? Comme toujours : promouvoir Tcl, aider à
> l'améliorer, aider les utilisateurs potentiels à choisir en toute
> connaissance de cause.
>
> J'en veux pour preuve que le 17 Décembre dernier, en dépit de mes
>
> Quoi qu'il en soit, Jibal, la controverse étant ce qui fait avancer la
> connaissance, continue de donner ton avis passionné ici où nous
> manquons cruellement de passion ces derniers temps. Modère juste un
> peu plus tes propos pour ne pas vexer les gens plus susceptibles que
> moi. ;^)
>
> --
> David Zolli
Je te réitère mes excuses. Loin de moi le désir de venir "troller"
d'une quelconque façon ce groupe de discussion... ;)
Je suis effectivement passionné par ce langage car, après en avoir
utilisé plusieurs autres, j'en reviens toujours à Tcl/Tk pour sa
simplicité (même si elle n'est qu'apparente car derrière cette façade
se cachent tout plein de subtilités que j'apprends au fur et à
mesure), sa compacité, ses possibilités énormes, ses librairies
diverses et variées et surtout son traitement très efficace des
expressions régulières dont j'ai tendance à faire parfois une
utilisation ...Immodérée ! ;)
Je l'utilise à la fois dans le cadre de mon travail (automatisation de
tâches sur plusieurs environnements UNIX avec Expect, en ce moment) et
pour mes loisirs (gestion à distance de serveurs de jeu) et vraiment,
comme on dit dans mon dialecte local: "C'est de la balle"... ;)
La seule chose qui m'attriste est de voir tous ces outils (dont
certains que j'apprécie) "morts" autour d'un langage lui-même bien
vivant et évoluant régulièrement.
Kroc
Quant à ma première réponse, c'est exactement ce que j'ai dit à voix
haute en voyant des captures d'écran. Tant de boutons alors que Tk est
si simple, ça m'a semblé bien compliqué. ;^)
--
David Zolli
Kroc
> La seule chose qui m'attriste est de voir tous ces outils (dont
> certains que j'apprécie) "morts" autour d'un langage lui-même bien
> vivant et évoluant régulièrement.
Oui, c'est le plus gros frein (selon moi) pour l'utilisation de tels
outils.
Si ton traitement de texte favoris est abandonné, c'est pas grave, tu
en prends simplement un autre. Avec ces GUI Builder, quoi qu'on en
dise, c'est moins simple.
--
David Zolli
AgainstTclWAR
Je suis pas vraiment de ton avis sur ce point.
En regardant un projet comme Visual Tcl (qui doit être le plus connu
et utilisé),
on peut voir que même si il est mort depuis 3 ans environ... il a été
téléchargé plus de 30 000 fois (sans compter les autres prj...).
Ne supportant pas les dernières versions de tcl/tk je trouve qu'il
s'agit d'une prouesse qui ne fait que traduire une vraie utilité/
besoin.
La-dessus c'est indiscutable, n'en déplaise à certain.
J'ai trouvé vos échanges très intéressant, notamment avec le créateur
de PureTkGUI.
Perso, j'utilise tcl/tk fréquemment et je pense que c'est le meilleur
langage de script qui existe.
Un GUI builder est pour moi le bienvenue et permet à certain de
trouver leur compte dans l'utilisation de ce langage ( si en plus, ça
peut le promouvoir c'est cool). Et je conviens que certains n'en
aient pas l'utilité.
Malgré tout j'encourage comme jibal, le projet PureTkGUI (concept
sympa avec un code vraiment bien fait, je tiens à le souligner).
J'encourage ceux qui n'en ont pas l'utilité ( si si ils
existent...lol) à continuer à lister les défauts qu'il peuvent trouver
à ces GUI Builder; comme ils l'ont déjà fait dans ce forum. (cela
pourra peut-être déboucher sur des propositions d'améliorations de
l'outil... qui sait ???.... )
On a chacun notre idée sur le tcl/tk, son utilisation.... sa
finalité..... la seule chose à faire est de lui faire une place dans
le monde de demain :
Then PLEASE NO TkWAR after TclWAR !
a bientot pour un prochain post
Jibal
> Je suis pas vraiment de ton avis sur ce point.
> En regardant un projet comme Visual Tcl (qui doit être le plus connu
> et utilisé),
> on peut voir que même si il est mort depuis 3 ans environ... il a été
> téléchargé plus de 30 000 fois (sans compter les autres prj...).
> Ne supportant pas les dernières versions de tcl/tk je trouve qu'il
> s'agit d'une prouesse qui ne fait que traduire une vraie utilité/
> besoin.
> La-dessus c'est indiscutable, n'en déplaise à certain.
C'est vrai que j'ai moi aussi été assez impressionné, dans un premier
temps, par Visual Tcl.
Par la suite, en revanche, en plus des plantages assez fréquents que
j'ai pu rencontrer avec cet outil, le code généré s'avère très
difficile à modifier et à compiler avec FreeWrap.
Or pour pouvoir distribuer mes programmes sur des plates-formes
Windows 2000 dépourvues de Tcl, je suis obligé de les compiler...
C'est pourquoi je me suis rabattu sur TkBuilder qui, s'il n'a pas le
chrome "à la VB" de Visual Tcl et peut sembler à première vue
effectivement assez "bordélique" ( un petit clin d'oeil à David !), a
le mérite de générer un code Tcl "propre", facilement modifiable et
"compilable" sans trop d'effort avec Freewrap.
J'espère donc à présent que PureTkGUI sera la bonne synthèse entre
VTcl pour son look et TkBuilder pour sa stabilité et pour son code
généré.
Kroc
> En regardant un projet comme Visual Tcl .../... il a été
> téléchargé plus de 30 000 fois (sans compter les autres prj...).
> Ne supportant pas les dernières versions de tcl/tk je trouve qu'il
> s'agit d'une prouesse qui ne fait que traduire une vraie utilité/
> besoin.
> La-dessus c'est indiscutable, n'en déplaise à certain.
Personne ne discute sa popularité. Néanmoins, 30000 téléchargement
c'est assez faible et télécharger ne veut pas dire utiliser de manière
régulière. ;^)
> .../...
> On a chacun notre idée sur le tcl/tk, son utilisation.... sa
> finalité..... la seule chose à faire est de lui faire une place dans
> le monde de demain :
> Then PLEASE NO TkWAR after TclWAR !
On est tous d'accord sur ce point. Toutefois, la discussion a été
(comme toujours ici) courtoise, intelligente et argumentée : parler de
guerre est très excessif, non ?
--
David Zolli
AgainstTclWAR
Pour Jibal : effectivement ce qui me dérange avec Visual Tcl est qu'il
rajoute du code qui ne devrait pas.
de plus je suis effectivement d'accord sur le fait qu'il ne constitue
pas une bonne base pour une évolution. Tandis que PureTKGUI offre de
bonnes
perspectives... et pourquoi pas devenir le GUI Builder de Tk ?,
n'oublions pas tout les autres langages qui utilise cette lib
graphique. Si un Gui Builder bien fichu pouvait générer du code Python
(Tkinter), Perl , ruby....... oups que de gros mots pour les fins
connaisseurs de tcl (comme moi d'ailleurs)... L'important est qu'il
soit fait en TCL, c'est tout. En tout cas je trouve assez élégant le
côté récurssif de PuretKGUI (développé par lui-même).
Pour David : Non je suis bien d'accord évidemment. Je souligne de
nouveau que vos remarques sont très intéressantes. Mais ce qui m'a
gêné en fait c'est que le sujet de Jibal ait été détourné. (d'où ces
postes du type ... non je veux pas dire ça...le prends pas comme çà
etc....
Loin de moi l'idée de vous faire la leçon par ce que Je le répéte vos
remarques sont pertinentes... mais elles auraient méritées un autre
post (GUI BUIlder utile ? pour ou contre ?).
Amicalement