ANN: untitled localisé
ulis
On peut y jouer avec tout clavier, y compris chinois ou Dvorak.
Téléchargement :
http://perso.wanadoo.fr/maurice.ulis/tcl/Games/untitled.tcl
ulis l'international
(coupeur de citrons patenté)
Kroc
> Le jeu untitled a été complètement remasterisé et localisé.
> On peut y jouer avec tout clavier, y compris chinois ou Dvorak.
Ah oui, ça marche. Sauf que je connais pas les règles et que sur Mac
c'est pas en couleur.
--
David Zolli - Kroc
ulis
> c'est pas en couleur.
T'as un moniteur noir et blanc ?
Il faut un moniteur en couleurs, désolé. La couleur est un des deux
critères de choix.
(va falloir se cotiser un jour)
T'aurais pas une boîte de peinture ?
Eric Hassold
Helas, meme boite de peinture, meme daltonisme ici, avec Tcl/Tk
"standard" comme avec eTcl pour MacOSX. La raison, toute bete: Tcl/Tk
sous Mac utilise Carbon, et ses widgets natifs. Et les boutons sous
Carbon sont d'un joli bleu translucide quand actifs, gris sinon, et ce
n'est pas l'option -background qui y change qqchose.
La solution, portable: remplacer les boutons par un autre widget plus
simple, e.g. un label:
foreach row $numlist \
{
foreach col $numlist \
{
label .$row-$col -width $size -height $size\
-image $img(i) -bd 2 -relief raised
bind .$row-$col <1> [list press .$row-$col]
grid .$row-$col -row $row -column $col
}
}
Et voila, sous MacOSX aussi, on peut voir la vie en rose... et bleu...
et vert...
Eric
-----
Eric Hassold
Evolane - http://www.evolane.com/
ulis
> "standard" comme avec eTcl pour MacOSX. La raison, toute bete: Tcl/Tk
> sous Mac utilise Carbon, et ses widgets natifs. Et les boutons sous
> Carbon sont d'un joli bleu translucide quand actifs, gris sinon, et ce
> n'est pas l'option -background qui y change qqchose.
Hm...
Donc Tk n'est plus portable ?
MacOSX lui est insupportable !
> La solution, portable: remplacer les boutons par un autre widget plus
> simple, e.g. un label:
>
> foreach row $numlist \
> {
> foreach col $numlist \
> {
> label .$row-$col -width $size -height $size\
> -image $img(i) -bd 2 -relief raised
> bind .$row-$col <1> [list press .$row-$col]
> grid .$row-$col -row $row -column $col
> }
> }
oky, considérez que c'est fait
ulis ulcéré par cette portabilité insupportée
ulis
X
et qui implémente le défaire/refaire.
Toujours le support du clavier chinois et du clavier Dvorak.
Copie d'écran (pour ceux qui sont en noir et blanc) :
http://perso.wanadoo.fr/maurice.ulis/tcl/Games/untitled.png
Téléchargement :
http://perso.wanadoo.fr/maurice.ulis/tcl/Games/untitled.tcl
ulis qui défait et qui refait
Eric Hassold
>> Helas, meme boite de peinture, meme daltonisme ici, avec Tcl/Tk
>> "standard" comme avec eTcl pour MacOSX. La raison, toute bete: Tcl/Tk
>> sous Mac utilise Carbon, et ses widgets natifs. Et les boutons sous
>> Carbon sont d'un joli bleu translucide quand actifs, gris sinon, et ce
>> n'est pas l'option -background qui y change qqchose.
>
> Hm...
> Donc Tk n'est plus portable ?
> MacOSX lui est insupportable !
Sans etre pro-Mac, pas sur que Mac soit le coupable. Juste l'eternel
dilemne entre widgets 100% portable vs. look natif. Et Tile ne fait
qu'accentuer le tout, sur toutes les plate-formes (avec comme argument
"les widgets Tk restent disponiblent pour ceux qui veulent user et
abuser des -background, -borderwidth, etc...).
Rien ne serait plus facile que de laisser Tk dessiner soi-meme les
boutons, radio, check, etc..., comme il le fait d'ailleurs sous X11.
C'est d'ailleurs ce qu'il faisait a une "lointaine" epoque avant que
retentisse la clameur populaire qui reclamait des interfaces au look
natif. Pour du 100% portable, on peut creer un Tk qui, quelque soit la
plate-forme, cree chaque toplevel comme une sorte de framebuffer, au
sein duquel il dessinerait soi-meme les widgets. On a developpe un
portable Tk utilisant SDL qui fonctionne ainsi, ce qui est a Tcl ce que
MIDP est a JAVA. Pour le coup, 100% portable, mais on peut aussi etre
sur que tout le monde se tournerait alors (enfin....plus encore) vers
d'autres toolkit, en reprochant a Tk de ne pas respecter le "look&feel"
auquel est habitue l'utilisateur final sur sa machine (si, si, c'est
important, l'opinion d'un utilisateur final! ;-))
A mon humble avis, le compromis est possible en considererant que les
widgets "evolues" (i.e. qui ont une semantique intrinseque) tels que
boutons, radio, check, combo, notebook sont des choses dont on ne doit
pas assumer du look precis (car avant tout du ressort de l'utilisateur
final, par. ex. dans le cas d'un utilisateur avec difficultes visuelles,
ayant choisi de larges polices et des couleurs tres contrastees), tandis
que des frames ou canvas peuvent etre utilises pour dessiner soit meme,
au pixel pres, de facon 100% portable, les objets graphiques tels que le
developpeur les concoit.
Allez, Tcl/Tk reste bien LA solution portable par excellence. Faut juste
prendre quelques precautions et habitudes.
Eric
(deja adepte de untitled sous PocketPC grace a la portabilite de Tcl/Tk)
ulis
> widgets "evolues" (i.e. qui ont une semantique intrinseque) tels que
> boutons, radio, check, combo, notebook sont des choses dont on ne doit
> pas assumer du look precis (car avant tout du ressort de l'utilisateur
> final, par. ex. dans le cas d'un utilisateur avec difficultes visuelles,
> ayant choisi de larges polices et des couleurs tres contrastees), tandis
> que des frames ou canvas peuvent etre utilises pour dessiner soit meme,
> au pixel pres, de facon 100% portable, les objets graphiques tels que le
> developpeur les concoit.
J'en conclus qu'en utilisant des boutons évolués dans mon jeu, j'ai
fait une erreur.
Je devrais même supprimer les labels et revenir au canvas.
C'est non seulement possible mais cohérent.
Dommage, car justement j'avais choisi LE jeu qui me permettait de
programmer facilement grâce aux boutons de Tk (un jeu = une proc).
Si tu as raison (et ça y ressemble fortement) Tk est en train de
passer à côté de la simplicité qui m'attire si fortement.
Il me reste à forger mes propres outils et mettre les bouchées
doubles pour mbutton.
J'aurai ainsi un widget SUPER-évolué qui permettra les deux usages.
Car finalement, si les boutons Tk avait l'option -jeu 1...
ulis
Miko
Miko
Sun a bien poussé Tcl/Tk a une époque, avant de décréter que Java.........
ulis
> "standard" comme avec eTcl pour MacOSX. La raison, toute bete: Tcl/Tk
> sous Mac utilise Carbon, et ses widgets natifs. Et les boutons sous
> Carbon sont d'un joli bleu translucide quand actifs, gris sinon, et ce
> n'est pas l'option -background qui y change qqchose.
J'ai mis le temps pour la réflexion (j'ai un cerveau-lent qui ne vole
pas haut)
mais quand même :
Si on spécifie une image pour un bouton, Tk n'en tient pas compte sous
Carbon ?
Moi j'appelle ça un bug. Et un gros.
Un énorme. Que dis-je ? Une montagne.
C'est gros comme un nez au milieu de la figure.
Ou c'est encore mon demi-neurone avachi qui me joue un tour ?
ulis qui compte les paquerettes (et qui comptait sur Tk)
Eric Hassold
Si c'etait le cas, oui, ca pourrait etre qualifie avec autant de
superlatifs negatifs. Mais... ce n'est pas tout a fait ca:
Si tu specifies une image, elle s'affiche bien dans le bouton, sous Mac
comme ailleurs, et c'est ce qu'il se passe dans ton code untitled.tcl.
Helas, la ou ca se gate, c'est que les images en questions ne
contiennent en fait que les chiffres (sous formes de disques), mais que
le reste de l'image est transparent, et que tu comptes sur la couleur de
fond du bouton, que tu specifies avec une option "-bg" propre a chaque
case. Tk fait ce qu'il faut, a savoir afficher ton image par dessus le
bouton lui meme, mais le hic, c'est que sous Mac, les boutons utilisent
le theme de l'interface graphique, c-a-d qu'ils sont bleus ou gris
translucide (selon etat), mais pas de la couleur specifiee par l'option
-background (alias -bg).
Dans le debat portabilite totale vs. look natif, les motivations et
arguments des partisans des deux camps sont acceptables. Dans l'interet
de la promotion de Tk, on peut comprendre que qu'un utilisateur mac qui
ecrit
pack [button .b -text "Ok"]
s'attende a voir apparaitre un bouton semblable aux autres boutons de
son bureau, pas a un carre gris uniforme. Il en va ainsi pour un
ensemble de widgets "elabores" (radiobutton, checkbutton, scale,
scrollbar, combobox si dispo, etc...), pour lesquels (presque) personne
n'ira presumer de leur look au pixel pres.
Je comprends que le cas du widget "button" soit un peu plus litigieux,
et qu'on puisse etre tente de le considerer comme ces widgets tres
generiques que sont les frames, labels, ou canvas, eux 100% portables.
Malgre tout, et parce qu'il suffit d'une ligne de Tcl pour transformer
un label en un widget qui lance une commande quand on clique dessus
(comme dans le correctif de untitled.tcl dans message precedent), j'ai
quand meme tendance a penser que la situation actuelle n'est pas si
mauvaise. Surtout, j'espere pas au point de ne plus "compter sur Tk"
pour nous pondre des petites merveilles d'applis graphiques portables! :-)
Kroc
> Hm...
> Donc Tk n'est plus portable ?
> MacOSX lui est insupportable !
>
> > La solution, portable: remplacer les boutons par un autre widget plus
> > simple, e.g. un label:
> >
> > foreach row $numlist \
> > {
> > foreach col $numlist \
> > {
> > label .$row-$col -width $size -height $size\
> > -image $img(i) -bd 2 -relief raised
> > bind .$row-$col <1> [list press .$row-$col]
> > grid .$row-$col -row $row -column $col
> > }
> > }
>
> oky, considérez que c'est fait
>
> ulis ulcéré par cette portabilité insupportée
En fait, je crois juste que Tk Aqua est une espèce de version
intermédiaire entre Tk 8.X et Tk 9.X tel qu'il est préfiguré par
Tile. En effet, point de -bg ou -fg avec tile :
http://tktable.sourceforge.net/tile/doc/button.html ni même de -font,
-height, -border, etc..
L'idée, semble-t-il, est de limiter au maximum les options de
configuration des widgets pour rendre l'interface plus homogène au
sein d'une même application, et plus portable d'une plate-forme à une
autre.
Dans ton cas, Maurice, ça rend ton jeu inutilisable sur OS X, mais je
peux t'assurer que la ribambelle de "bricolages" nécessaires pour
rendre une application Tk "buvable" sur linux/gnome (tel gtklook.tcl)
ET fonctionnelle sous Windaube tient plus de l'acrobatie que de la
programmation. Dans mon cas, Tile est vraiment, *vraiment*, une
amélioration ! Même si je t'accorde volontier que pour des anciens de
Tk comme nous, c'est parfois frustrant de ramasser un "unknow option
-bg" de temps en temps ;-)
ulis
> intermédiaire entre Tk 8.X et Tk 9.X tel qu'il est préfiguré par
> Tile. En effet, point de -bg ou -fg avec tile :
> http://tktable.sourceforge.net/tile/doc/button.html ni même de -font,
> -height, -border, etc..
> L'idée, semble-t-il, est de limiter au maximum les options de
> configuration des widgets pour rendre l'interface plus homogène au
> sein d'une même application, et plus portable d'une plate-forme à une
> autre.
Je comprends bien le principe et je l'apprécie :
je suis en train de développer un package de style visuel qui est un
peu l'équivalent de Tile.
Mais j'ai regardé le lien sur le bouton de Tile : il y a toujours des
options -image et -compound. Et pour moi le comportement de Tk sur Aqua
est un bug. Et un gros.
On ne décrit pas une option et son comportement dans la doc pour faire
autrement en pratique. Sinon, c'est du vice (et versa).
ulis l'optionnel
Kroc
> Je comprends bien le principe et je l'apprécie :
> je suis en train de développer un package de style visuel qui est un
> peu l'équivalent de Tile.
>
> Mais j'ai regardé le lien sur le bouton de Tile : il y a toujours des
> options -image et -compound. Et pour moi le comportement de Tk sur Aqua
> est un bug. Et un gros.
> On ne décrit pas une option et son comportement dans la doc pour faire
> autrement en pratique. Sinon, c'est du vice (et versa).
En ce qui concerne Tk je suis d'accord avec toi : il n'est pas normal
d'ignorer une option. La bonne solution aurait été d'utiliser le fond
Aqua si et seulement si -bg n'est pas spécifié.
Mais sans vouloir m'ériger en défenseur d'OS X et de Tk Aqua, l'un
comme l'autre sont encore très jeunes, donc perfectibles par rapport
à ce qui existe pour Windows et Linux.
D'autre part, l'uniformité forcée des interfaces Mac est un vrai plus
pour les utilisateurs non-avertis : tout est là où on l'attend et les
formes et couleurs sont harmonieuses (mais c'est pas de bol si on
n'aime pas). N'empêche que c'est bien mieux que les looks
hétéroclites (qui parfois oscillent entre le farfelu et l'inepte) et
les menus à la va-là-comme-je-te-pousse de chez Windows Linux. Comme
quoi, parfois, la liberté créatrice conduit à l'anarchie. ;-)
Quant à Tile, il a été choisi de virer (entre autres) l'option -bg
avec message d'erreur à la clé : ce qui est cohérent à défaut
d'être compatible avec Tk.
ulis
> En ce qui concerne Tk je suis d'accord avec toi : il n'est pas normal
> d'ignorer une option. La bonne solution aurait été d'utiliser le fond
> Aqua si et seulement si -bg n'est pas spécifié.
Chorus
C'est le fond du problème : une image doit montrer le fond là où
elle est transparente.
Je ne comprend pas que Tk déroge.
Pour moi un bouton Tk Aqua ne devrait avoir le look Aqua que si on ne
précise rien de l'aspect (-image, -bg...) comme sous les autres OS.
> Mais sans vouloir m'ériger en défenseur d'OS X et de Tk Aqua, l'un
> comme l'autre sont encore très jeunes, donc perfectibles par rapport
> à ce qui existe pour Windows et Linux.
Chorus
> D'autre part, l'uniformité forcée des interfaces Mac est un vrai plus
> pour les utilisateurs non-avertis : tout est là où on l'attend et les
> formes et couleurs sont harmonieuses (mais c'est pas de bol si on
> n'aime pas). N'empêche que c'est bien mieux que les looks
> hétéroclites (qui parfois oscillent entre le farfelu et l'inepte) et
> les menus à la va-là-comme-je-te-pousse de chez Windows Linux. Comme
> quoi, parfois, la liberté créatrice conduit à l'anarchie. ;-)
Chorus
> Quant à Tile, il a été choisi de virer (entre autres) l'option -bg
> avec message d'erreur à la clé : ce qui est cohérent à défaut
> d'être compatible avec Tk.
Chorus
J'ajoute que Tile ne cherche pas (et n'a pas à chercher) la
compatibilité avec Tk.
ulis la bouche en coeur