J'ai essaye de traduire le tutoriel. Mais certains passages me sont incomprehensibles ou restent imprecis par ignorance de Squeak de ma part. Je vous laisse la traduction au bon soin d'en corriger les erreurs et si cela vous semble utile, de la mettre toute belle dans le squeak.fr... Bon courage et Merci
1. Vue d'ensemble des agencements en tableau
Les agencements en tableau (table layouts) (cadrages d'AKA) definissent une disposition generale mono ou bidimensionnelle des submorphs.
1.1 Parametres communs des agencements
XXXXXXXX
Exemple 1 : Parametres communs des agencements en tableau
# layoutInset : ecart entre les bords haut-gauche des morphs inclus et incluant. Ecart identique entre les bords bas-droite des morphs inclus et incluant
# cellInset : ecart entre le bord bas-droit d'un morph inclus et le bord haut-gauche d'un autre morph inclus. (distance horizontale, distance verticale)
# listDirection : direction principale de l'agencement. Quatre possibles : # leftToRight, # rightToLeft, # topToBottom, ou # bottomToTop. Si wrapDirection n'est pas definie, l'agencement est une liste unidimensionnelle.
# wrapDirection : direction secondaire de l'agencement. Utilisee s'il n'y a pas assez d'espace pour l'agencemment principal. Cinq possibles : # leftToRight, # rightToLeft, # topToBottom, # bottomToTop) et # none indiquant que l'agencement est unidimensionnel
Note : layoutInset est une propriete generale qui s'applique a tout agencement. Les autres proprietes ne concernent que les agencements en tableau.
1.2 Contraintes communes au reformatage des morphs
Deux proprietes (# hResizing et # vResizing) contrôlent les dimensions du morph. Si le reformatage est # spaceFill, le morph inclus occupe l'espace assure par le morph incluant. # shrinkWrap, le morph incluant entoure etroitement tous les morphs inclus. # rigid, aucun reformatage n'est applique.
XXXXXXXXXXXXXX Figure 2: Example resizing constraints
Quelques remarques necessaires Le reformatage # spaceFill ne s'applique que si l'agencement est active et le morph incluant a une disposition tableau active. Sinon le reformatage est defini comme # rigide.
Exemple : 1) le rectangle jaune : # shrinkWrap 2) Rectangle rouge sans agencement (halo:layout) 3) Rectangle jaune #spaceFill , le rectangle jaune ne rempli pas le rectangle rouge 4) Rectangle rouge "tableau" le rectangle jaune remplira le rectangle rouge
La contrainte #shrinkWrap ne s'applique que si le morph incluant a des morphs inclus .Sinon il est defini comme # rigid ( le morph ne se reformatera pas automatiquement).
Le cas morph #spaceFill inclus dans un morph #shrinkWrap depend d'une propriete supplementaire : # rubberBandCells : Si elle est "vraie" le format minimal sera choisi
Ainsi, si #rubberBandCells est vrai, l'agencement ne peut jamais etre automatique (rappelez-vous, n'importe quelle disposition calculee aura comme consequence la taille minimale). Mais si #rubberBandCells est faux, le reformatage sera incrementalement calcule.
XXXXXXXXXXXX * Exemple 3 : L'effet de # rubberBandCells
A gauche, #rubberBandCells vrai : taille minimale possible . A droite # rubberBandCells faux : le rectangle (rouge) externe est reformate.
La strategie appropriee n'est pas toujours la meme. Le developpeur pense en taille minimale, mais l'usager desire pouvoir la modifier.
2. Le processus d'agencement
Le processus de disposition est declenche par le message #fullBounds envoye au morph. Si le recepteur a besoin d'un reformatage, il declenche le processus par Morph>>doLayoutIn : newBounds
Il s'appelle de deux endroits differents (one of which is #fullBounds and the other one is through the recursive layout process which is covered later on). La methode calcule d'abord les dimensions nouvelles des submorphs puis applique ensuite les contraintes du morph incluant aux dimensions nouvelles des submorphs.
2.1 Calcul des dimensions nouvelles des submorphs (LayoutPolicy>>layout:in:) Cette methode debute le processus . Elle prend un certain morph comme argument et calcule le nouvel agencement de son submorph base sur les ->LayoutProperties d'arguments et ses ->LayoutProperties de submorphs.
Pour les formats en tableau le processus a quatre phases. Dans la premiere etape, les tailles minimales sont calculees pour tous les submorphs . Puis tailles minimales et agencement actuel des morphs permettent un nouveau calcul La troisieme etape repartie les espaces restant. Enfin les nouvelles limites de chaque morph sont definies.
2.2 Calcul des tailles minimales la premiere etape enumere les submorphs et calcule la taille minimale possible de chacun. Trois facteurs sont pris en compte : # minExtent enregistre par un submorph, # minCellSize enregistre par le proprietaire, et # maxCellSize enregistre par le proprietaire. Tous les deux, # minCellSize et # maxCellSize limite # minExtent enregistre par le morph. Cette etape delaisse un certain nombre d'autres proprietes pour aller plus rapidement.
Proprietes utilisees du morphs incluant : # minCellSize # maxCellSize # reverseTableCells
Truc : Rendre egales # minCellSize et # maxCellSize du morph incluant obligent les elements a adopter la meme taille
Proprietes utilisees des morphs inclus : # disableTableLayout -voir plus loin # minWidth - voir plus loin # minHeight - voir plus loin
2.3 Calcul de l'agencement cette etape prend en compte l'agencement anterieur, les limites precedentes et nouvelles, et les tailles minimales ci-dessus calculees, et calcule un agencement fonde sur
Proprietes utilisees du morph incluant # listDirection # wrapDirection # listSpacing # cellSpacing # cellInset
Proprietes utilisees du morpph inclus : <none>
2.4 Redistribuer l'espace disponible
Proprietes utilisees du morph incluant : # rubberBandCells # hResizing # vResizing # listCentering # wrapCentering
Proprietes utilisees des morphs inclus: # hResizing # vResizing # spaceFillWeight
2.5 Faire appliquer les nouvelles limites par chaque sous-morphs (par Morph>>layoutInBounds : les newBounds) Les morphs s'inscrivent dans les limites calculees.
Proprietes utilisees du morph incluant : # cellPositioning Proprietes utilisees des sous-morphs : # hResizing # vResizing
2.6 Appliquer les contraintes de formatage Si une des proprietes (# hResizing, et # vResizing) est # shrinkWrap le morph incluant est ajuste a la somme des dimensions de ses submorphs (dans Morph>>adjustLayoutBounds). Ceci est fait (dans #adjustLayoutBounds) de sorte que la taille ajustee ne devienne pas plus petite que la largeur ou la taille minimale definie par le recepteur (voir egalement : 'tailles minimales de calcul pour width/height minimal).
3. Description de toutes les proprietes liees aux agencements
Quelques details supplementaires....
3.1 Proprietes d'enfant :
# hResizing definit les contraintes de la côte horizontale. Valeurs possibles : # rigide, # shrinkWrap, et # spaceFill.
# vResizing Definit les contraintes de la côte verticale. Valeurs possibles : # rigide, # shrinkWrap, et # spaceFill.
# disableTableLayout Cette propriete exclut un submorph du processus general d'agencement (voir le schema 1 dans lequel tous les elements decoratifs ont ete exclus de la disposition de table).
# spaceFillWeight Cette propriete definit la priorite de chaque submorphs lors des conflits concernannt la contrainte #paceFill
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Exemple 4 : L'effet de # spaceFillWeight
# minWidth largeur minimale d'un morph.
# minHeight taille minimale d'un morph.
3.2 Proprietes du morph incluant :
# cellInset distance entre deux elements dans un tableau (voir l'exemple 1).
# cellPositioning definit comment un submorph s'aligne dans les limites calculees. Dans beaucoup de cas, les limites calculees n'adapteront pas un submorph exactement (comme une liste contenant des elements avec differentes tailles). # la propriete cellPositioning definit ou les limites du submorph et les limites calculees devraient etre alignees. Valeurs possibles : # topLeft, # topRight, # bottomLeft, # bottomRight, # leftCenter, # rightCenter, # topCenter, # bottomCenter, et # center.
# cellSpacing inutilise et a ne plus utiliser
# layoutInset L'encart (symetrique) a utiliser pour la disposition d'enfant. Base sur les limites interieures du proprietaire (par exemple, les limites dans tout cadre) des encarts de cette propriete l'agencement calcule entier bon du coin gauche et inferieur superieur.
# listDirection direction 'primaire 'de liste Valeurs possibles : # leftToRight, # rightToLeft, # topToBottom, et # bottomToTop (voir l'exemple 1).
# listCentering decrit comment tous les submorphs doivent s'aligner dans les limites du morphs incluant si'il reste de l'espace disponible Valeurs possibles sont # topLeft, # bottomRight, # ccenter, et # justified.
XXXXXXXX Exemple 5 : Different # valeurs listCentering (# topLeft, # centre, # bottomRight, # justifie)
# listSpacing definit si les differentes lignes ont la meme taille ou pas. Valeurs possibles: # none ( tailles inegales) et # egal (tailles egales ).
# reverseTableCells Si vrais, tous les submorphs sont utilises dans l'ordre des inverse des submorphs.
# rubberBandCells regle le cas ou coexistent # spaceFill et # shrinkWrap Voir l'exemple 3
# wrapDirection direction a suivre dans un tableau ou l'espace est insuffisant . # none indique qu'aucun retour (wrapping) n'aura lieu. Sinon les submorphs suuivront la direction indiquee : # topToBottom, # bottomToTop, # leftToRight, ou #rightToLeft.
# wrapCentering equivalent de # listCentering, s'applique aux lignes entieres
# minCellSize taille minimale pour chaque element dans un tableau
# maxCellSize taille maximum pour chaque element dans un tableau
4. Differences connues avec AlignmentMorphs
Il y a quelques differences entre la façon dont AlignmentMorphs fonctionnait et la façon dont le nouvel agencement en tableau fonctionne.
4.1 Vieux #spaceFill
# spaceFill etait interpretee comme # shrinkWrap quand un morph n'etait pas inclus dans un autre AlignmentMorph. Ce n'est plus le cas et # spaceFill doit etre change en # shrinkWrap
4.2 Correspondances entre les variables d'instance et les proprietes d'agencement
# orientation Surchargee par # listDirection (orientation etait seulement #horizontal ou # vertical ; #listDirection est plus precise).
# centering Fondamentalement remplace par # wrapCentering. # centering definissait le placement d'une ligne entiere (ou de la colonne) pour le calcul. C'est l'equivalent de # wrapCentering. La conversion reelle est un peu plus compliquee puisque le positionnement des elements dans les limites calculees (par exemple, # cellPositioning) doit etre aussi bien change.
# hResizing/# vResizing les deux proprietes ont fondamentalement la meme signification a l'exception notee dans la section 4.1.
# encart equivalent de # layoutInset.
# minCellSize equivalent de # minCellSize