On récupère les coordonnées (x,y) du coin supérieur gauche du carré pointé.
On récupère la scène où se trouve le carré pointé ; dans notre cas, ce sera l'instance
(unique) de SceneMosaiQ. Notons que, comme on ne fait aucune hypothèse sur la
scène, on pourrait très bien réutiliser la classe CarreMosaiQ dans n'importe quelle
autre scène, instance directe ou indirecte de QGraphicsScene.
L'opération de fragmentation consiste en fait à supprimer le carré pointé de la scène
et de le remplacer par quatre nouveaux. Il peut sembler dangereux a priori d'enlever
de la scène l'élément sur lequel on est précisément en train d'agir. Ne sommes-nous
pas en train de scier la branche sur laquelle nous sommes assis ? En fait, il n'y a
aucun risque dans cette opération : la méthode removeItem ne fait que remettre en
coulisse l'élément qui était sur scène ; il disparaît automatiquement de la vue (et
donc de l'écran), mais il existe toujours en mémoire ; tant qu'on a une référence vers
cet élément, on peut continuer à invoquer des méthodes sur lui, voire le replacer sur
la scène ou le placer sur une autre scène. Dans le cas particulier de notre
application, au sortir de la méthode fragmente, le carré enlevé de la scène ne sera
plus référencé par aucun objet et sera effectivement détruit ; la seule exception est
l'élément carré initial, qui n'est jamais détruit car référencé dans l'attribut
carreMosaiQUnivers de la scène (voir SceneMosaiQ.__init__).
Note > Une autre technique possible aurait été de rendre le carré invisible, en
faisant self.setVisible(False) : l'élément reste alors sur la scène, mais n'est plus
montré sur la vue. Visuellement, le résultat est le même, mais on consomme
inutilement de la mémoire. Par contre, on gagne un tout petit peu en vitesse, car
la gestion interne de données par le framework est plus simple ; le gain est tout à
fait imperceptible dans le cas présent mais on peut le noter avec la technique de
fragmentation continue exposée plus loin. On a donc ici un cas classique de
compromis entre performance et consommation mémoire.
Le cœur de l'algorithme est ici : la boucle fait quatre itérations en donnant chaque
fois les coordonnées (dx,dy) du nouveau carré à créer, relatives au coin supérieur
gauche (x,y) du grand carré qu'on vient de faire disparaître. À chaque itération, on
crée une nouvelle instance de CarreMosaiQ, avec le coin supérieur gauche aux
coordonnées scène (x+dx,y+dy). On aurait bien entendu pu faire tout ceci en quatre
instructions distinctes, mais, comme on l'a déjà vu, la syntaxe de Python permet
d'éviter beaucoup de redondances. Après cette boucle, on a quatre nouveaux carrés
représentés à l'écran ; chacun a une couleur aléatoire et est prêt à réagir
238
On récupère la scène où se trouve le carré pointé ; dans notre cas, ce sera l'instance
(unique) de SceneMosaiQ. Notons que, comme on ne fait aucune hypothèse sur la
scène, on pourrait très bien réutiliser la classe CarreMosaiQ dans n'importe quelle
autre scène, instance directe ou indirecte de QGraphicsScene.
L'opération de fragmentation consiste en fait à supprimer le carré pointé de la scène
et de le remplacer par quatre nouveaux. Il peut sembler dangereux a priori d'enlever
de la scène l'élément sur lequel on est précisément en train d'agir. Ne sommes-nous
pas en train de scier la branche sur laquelle nous sommes assis ? En fait, il n'y a
aucun risque dans cette opération : la méthode removeItem ne fait que remettre en
coulisse l'élément qui était sur scène ; il disparaît automatiquement de la vue (et
donc de l'écran), mais il existe toujours en mémoire ; tant qu'on a une référence vers
cet élément, on peut continuer à invoquer des méthodes sur lui, voire le replacer sur
la scène ou le placer sur une autre scène. Dans le cas particulier de notre
application, au sortir de la méthode fragmente, le carré enlevé de la scène ne sera
plus référencé par aucun objet et sera effectivement détruit ; la seule exception est
l'élément carré initial, qui n'est jamais détruit car référencé dans l'attribut
carreMosaiQUnivers de la scène (voir SceneMosaiQ.__init__).
Note > Une autre technique possible aurait été de rendre le carré invisible, en
faisant self.setVisible(False) : l'élément reste alors sur la scène, mais n'est plus
montré sur la vue. Visuellement, le résultat est le même, mais on consomme
inutilement de la mémoire. Par contre, on gagne un tout petit peu en vitesse, car
la gestion interne de données par le framework est plus simple ; le gain est tout à
fait imperceptible dans le cas présent mais on peut le noter avec la technique de
fragmentation continue exposée plus loin. On a donc ici un cas classique de
compromis entre performance et consommation mémoire.
Le cœur de l'algorithme est ici : la boucle fait quatre itérations en donnant chaque
fois les coordonnées (dx,dy) du nouveau carré à créer, relatives au coin supérieur
gauche (x,y) du grand carré qu'on vient de faire disparaître. À chaque itération, on
crée une nouvelle instance de CarreMosaiQ, avec le coin supérieur gauche aux
coordonnées scène (x+dx,y+dy). On aurait bien entendu pu faire tout ceci en quatre
instructions distinctes, mais, comme on l'a déjà vu, la syntaxe de Python permet
d'éviter beaucoup de redondances. Après cette boucle, on a quatre nouveaux carrés
représentés à l'écran ; chacun a une couleur aléatoire et est prêt à réagir
238