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
bonjour,
est-ce que : jpruvot at etu.info.unicaen.fr est membre de cette liste? Je l'espere! Si oui, tu demandais il y a un certan temps sur squeak-dev pourquoi tu n'arrivais pas à afficher des formes simples en mdl...Apparemment tu n'avais pas reçu de réponse..Or, je rencontre aujourd'hui exactement le même probleme..Aurais tu trouvé une solution? J'arrive à afficher des formes simples en vrml, comme la sphere, mais j'ai besoin de certaines formes mdl, comme le tube ou le demi tore . En effet, appremment, les formes extrudées en vrml passent terriblement mal, avec beaucoup d'erreurs dans squeak, qu'elles soient sous la forme d'un node Extrusion (elles ne s'affichent pas du tout) ou comme des IndexedFacedSet (s'affichent mais avec des erreurs sur les parties creuses ou concaves)
Merci! Remi
Le lun 29/09/2003 à 18:02, Remi Sussan a écrit :
bonjour,
est-ce que : jpruvot at etu.info.unicaen.fr est membre de cette liste? Je l'espere! Si oui, tu demandais il y a un certan temps sur squeak-dev pourquoi tu n'arrivais pas à afficher des formes simples en mdl...Apparemment tu n'avais pas reçu de réponse..Or, je rencontre aujourd'hui exactement le même probleme..Aurais tu trouvé une solution? J'arrive à afficher des formes simples en vrml, comme la sphere, mais j'ai besoin de certaines formes mdl, comme le tube ou le demi tore . En effet, appremment, les formes extrudées en vrml passent terriblement mal, avec beaucoup d'erreurs dans squeak, qu'elles soient sous la forme d'un node Extrusion (elles ne s'affichent pas du tout) ou comme des IndexedFacedSet (s'affichent mais avec des erreurs sur les parties creuses ou concaves)
Je t'invite à prendre contact directement avec lui, car il n'est pas abonné sur cette liste je crois.
Carette.pierre-marie a écrit:
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
J'ai commencé à tout relire et à tout reprendre en espérant apporter un mieux. J'ai surtout rajouté les accents par ce que le français sans accents c'est vraiment pas beau. J'ai aussi systématiquement enlevé l'espace que tu avais mis entre # et le nom des propriétés par ce que je suis pas sûr que squeak apprécie si il les trouve. Mais c'est un long travail et j'arriverai pas au bout en une seule fois.
Le truc ultime ce serait bien sûr de faire une version en français du fichier .pr
En tous les cas merci à pierre-marie pour ce travail courageux.
Alexandre
- Vue d'ensemble des agencements en tableau.
Les agencements en tableau (table layouts) (cadrages d'AKA) définissent une disposition générale mono ou bidimensionnelle des submorphs.
1.1 Paramètres communs des agencements.
XXXXXXXX
Exemple 1 : Paramètres communs des agencements en tableau.
#layoutInset : écart entre les bords internes du contenant et ceux des morphs contenus. Les écarts sont identiques entre les bords bas-droite des morphs inclus et incluant et les bords haut-gauche.
#cellInset : permet le réglage de la distance entre deux léméents de l'arangement. cellInset est une paire de coordonnées dont l'abcisse indique la distnace qui sépare horizontalement les morphs. L'ordonnée indique elle la distance qui sépare les morphs verticalement.
#listDirection : il s'agit de la direction principale de l'agencement. Quatre directions sont possibles : #leftToRight, #rightToLeft, #topToBottom, ou #bottomToTop (gauche à droite, droite à gauche, du haut vers le bas, du bas vers le haut). Si #wrapDirection n'est pas définie, l'agencement est une liste unidimensionnelle.
# wrapDirection : il s'agit de la direction secondaire de l'agencement. Elle est utilisée s'il n'y a pas assez d'espace sur une ligne de la direction principale. Cinqs directions sont possibles : #leftToRight, #rightToLeft, #topToBottom, #bottomToTop) et #none indiquant que l'agencement est unidimensionnel.
Note : layoutInset est une propriété générale qui s'applique à toute sorte d'agencement. Les autres propriétés ne concernent que les agencements en tableau.
1.2 Contraintes communes au reformatage des morphs.
Deux propriétés (#hResizing et #vResizing) contrôlent les contraintes sur les dimensions du morph. Si le reformatage est #spaceFill, le morph occupe tout l'espace qui lui est offert par le morph qui le contient. La contrainte est donc donnée par le morph qui contient notre morph avec TableLayout. #shrinkWrap, le morph entoure étroitement tous ses enfants. La contrainte n'est plus donnée par le père mais par les enfants. #rigid, aucune contrainte n'est spécifiée. Le reformatage automatique n'a pas lieu.
XXXXXXXXXXXXXX Figure 2: Exemple de constraintes sur les dimensionsQuelques sont remarques nécessaires : Le reformatage #spaceFill ne s'applique que si le morph père possède une police d'agencement acitve et réglée de type TableLayout. Sans ça la contrainte #spaceFill est équivalente à #rigid.
Exemple :
- Poser la contrainte #shrinkWrap sur le rectangle jaune (en cliquant
sur le boutton prévu à effet). 2) Supprimer la police d'arrangement du rectangle rouge. Pour ce faire dans le menu du halo du rectangle sélectionner 'layout' puis 'no layout'. Le menu du rectangle s'obtient en cliquant plusieurs fois avec le bouton halo de la souris jusqu'à ce que ce soit le halo du rectangle rouge qui apparaisse. 3) Poser la contrainte #shrinkFill sur le rectangle jaune, le rectangle jaune ne rempli pas le rectangle rouge comme on pourrait s'y attendre. 4) Mettre une police d'arrange 'table layout' sur le rectangle rouge. Cette fois le rectangle jaune remplit le rectangle rouge.
La contrainte #shrinkWrap ne s'applique que si le morph a des enfants. Si le morph n'a pas d'enfants la contrainte #shrinkWrap se comporte comme la contrainte #rigid (le morph ne se reformatera pas automatiquement).
La suite de ma relecture pour bientôt si elle intéresse du monde.
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.
- 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).
- 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
- 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
Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeak-fr
Je vous suggere d'utiliser le wiki francophone comme cela d'autre peuvent le lire sans etre dans la mailing-list
http://www.iutc3.unicaen.fr:8000/fsug/
stef
On Lundi, sep 29, 2003, at 22:03 Europe/Zurich, Alexandre Benoit wrote:
Carette.pierre-marie a écrit:
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
J'ai commencé à tout relire et à tout reprendre en espérant apporter un mieux. J'ai surtout rajouté les accents par ce que le français sans accents c'est vraiment pas beau. J'ai aussi systématiquement enlevé l'espace que tu avais mis entre # et le nom des propriétés par ce que je suis pas sûr que squeak apprécie si il les trouve. Mais c'est un long travail et j'arriverai pas au bout en une seule fois.
Le truc ultime ce serait bien sûr de faire une version en français du fichier .pr
En tous les cas merci à pierre-marie pour ce travail courageux.
Alexandre
- Vue d'ensemble des agencements en tableau.
Les agencements en tableau (table layouts) (cadrages d'AKA) définissent une disposition générale mono ou bidimensionnelle des submorphs.
1.1 Paramètres communs des agencements.
XXXXXXXX
Exemple 1 : Paramètres communs des agencements en tableau.
#layoutInset : écart entre les bords internes du contenant et ceux des morphs contenus. Les écarts sont identiques entre les bords bas-droite des morphs inclus et incluant et les bords haut-gauche.
#cellInset : permet le réglage de la distance entre deux léméents de l'arangement. cellInset est une paire de coordonnées dont l'abcisse indique la distnace qui sépare horizontalement les morphs. L'ordonnée indique elle la distance qui sépare les morphs verticalement.
#listDirection : il s'agit de la direction principale de l'agencement. Quatre directions sont possibles : #leftToRight, #rightToLeft, #topToBottom, ou #bottomToTop (gauche à droite, droite à gauche, du haut vers le bas, du bas vers le haut). Si #wrapDirection n'est pas définie, l'agencement est une liste unidimensionnelle.
# wrapDirection : il s'agit de la direction secondaire de l'agencement. Elle est utilisée s'il n'y a pas assez d'espace sur une ligne de la direction principale. Cinqs directions sont possibles : #leftToRight, #rightToLeft, #topToBottom, #bottomToTop) et #none indiquant que l'agencement est unidimensionnel.
Note : layoutInset est une propriété générale qui s'applique à toute sorte d'agencement. Les autres propriétés ne concernent que les agencements en tableau.
1.2 Contraintes communes au reformatage des morphs.
Deux propriétés (#hResizing et #vResizing) contrôlent les contraintes sur les dimensions du morph. Si le reformatage est #spaceFill, le morph occupe tout l'espace qui lui est offert par le morph qui le contient. La contrainte est donc donnée par le morph qui contient notre morph avec TableLayout. #shrinkWrap, le morph entoure étroitement tous ses enfants. La contrainte n'est plus donnée par le père mais par les enfants. #rigid, aucune contrainte n'est spécifiée. Le reformatage automatique n'a pas lieu.
XXXXXXXXXXXXXX Figure 2: Exemple de constraintes sur lesdimensions
Quelques sont remarques nécessaires : Le reformatage #spaceFill ne s'applique que si le morph père possède une police d'agencement acitve et réglée de type TableLayout. Sans ça la contrainte #spaceFill est équivalente à #rigid.
Exemple :
- Poser la contrainte #shrinkWrap sur le rectangle jaune (en
cliquant sur le boutton prévu à effet). 2) Supprimer la police d'arrangement du rectangle rouge. Pour ce faire dans le menu du halo du rectangle sélectionner 'layout' puis 'no layout'. Le menu du rectangle s'obtient en cliquant plusieurs fois avec le bouton halo de la souris jusqu'à ce que ce soit le halo du rectangle rouge qui apparaisse. 3) Poser la contrainte #shrinkFill sur le rectangle jaune, le rectangle jaune ne rempli pas le rectangle rouge comme on pourrait s'y attendre. 4) Mettre une police d'arrange 'table layout' sur le rectangle rouge. Cette fois le rectangle jaune remplit le rectangle rouge.
La contrainte #shrinkWrap ne s'applique que si le morph a des enfants. Si le morph n'a pas d'enfants la contrainte #shrinkWrap se comporte comme la contrainte #rigid (le morph ne se reformatera pas automatiquement).
La suite de ma relecture pour bientôt si elle intéresse du monde.
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.
- 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).
- 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
- 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
Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeak-fr
Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeak-fr
squeak-fr@lists.squeakfoundation.org
-
Alexandre Benoit -
Carette.pierre-marie -
ducasse -
Remi Sussan -
Serge Stinckwich