Comme on a fait des facteurs d'agrandissement aléatoires indépendants selon les axes,
on obtient des effets de déformation notables (pour s'en affranchir, il suffit de placer la
valeur aléatoire dans une variable f et appeler vueAux.scale(f,f)). On constate par
ailleurs que des barres de défilement ont été placées automatiquement sur les vues qui
ne peuvent montrer la scène en entier. En déplaçant le smiley sur une des vues, on
constate à nouveau la synchronisation entre toutes les vues. Sur la base des lignes de
code qui précèdent, on peut aisément pousser le framework plus loin en augmentant
encore le nombre de vues à créer.
Note > Dans la boucle for, on range les vues dans une liste vuesAux uniquement pour
éviter qu'elles ne soient détruites à chaque itération. Sans cela, l'assignation de la
variable vueAux détruit la vue précédemment assignée, car cette dernière n'est plus
référencée (c'est comme cela que Python récupère la mémoire qui n'est plus utilisée).
Concrètement, sans l'instruction vuesAux.append(vueAux), le programme va s'exécuter
sans erreur mais… on n'aura que la dernière vue créée dans la boucle.
Bien évidemment, tout ce qui précède a uniquement vocation de démonstration : la
plupart des applications n'utilisent en fait qu'une vue ou deux, font des zooms sans
déformation et se passent de rotation. L'exemple montre que le principe de séparation
scène et vue fonctionne parfaitement, sans causer de ralentissement. Bien sûr, l'exemple
donné ici ne montre qu'une scène minimale avec juste cinq éléments ; au chapitre
MosaiQ : une démo technologique ! , on verra qu'une scène peut contenir sans souffrir
des dizaines de milliers d'éléments. Rappelons qu'on programme bien ici en Python,
langage interprété qui a parfois une réputation de lenteur — un point qu'il faudrait
grandement nuancer par ailleurs ! En fait, dans les applications PyQt, Python fait en
général très peu de choses : c'est un chef de chantier qui sous-traite les opérations
graphiques lourdes à des outils super-optimisés écrits en C++, voire à la carte
graphique.
212
on obtient des effets de déformation notables (pour s'en affranchir, il suffit de placer la
valeur aléatoire dans une variable f et appeler vueAux.scale(f,f)). On constate par
ailleurs que des barres de défilement ont été placées automatiquement sur les vues qui
ne peuvent montrer la scène en entier. En déplaçant le smiley sur une des vues, on
constate à nouveau la synchronisation entre toutes les vues. Sur la base des lignes de
code qui précèdent, on peut aisément pousser le framework plus loin en augmentant
encore le nombre de vues à créer.
Note > Dans la boucle for, on range les vues dans une liste vuesAux uniquement pour
éviter qu'elles ne soient détruites à chaque itération. Sans cela, l'assignation de la
variable vueAux détruit la vue précédemment assignée, car cette dernière n'est plus
référencée (c'est comme cela que Python récupère la mémoire qui n'est plus utilisée).
Concrètement, sans l'instruction vuesAux.append(vueAux), le programme va s'exécuter
sans erreur mais… on n'aura que la dernière vue créée dans la boucle.
Bien évidemment, tout ce qui précède a uniquement vocation de démonstration : la
plupart des applications n'utilisent en fait qu'une vue ou deux, font des zooms sans
déformation et se passent de rotation. L'exemple montre que le principe de séparation
scène et vue fonctionne parfaitement, sans causer de ralentissement. Bien sûr, l'exemple
donné ici ne montre qu'une scène minimale avec juste cinq éléments ; au chapitre
MosaiQ : une démo technologique ! , on verra qu'une scène peut contenir sans souffrir
des dizaines de milliers d'éléments. Rappelons qu'on programme bien ici en Python,
langage interprété qui a parfois une réputation de lenteur — un point qu'il faudrait
grandement nuancer par ailleurs ! En fait, dans les applications PyQt, Python fait en
général très peu de choses : c'est un chef de chantier qui sous-traite les opérations
graphiques lourdes à des outils super-optimisés écrits en C++, voire à la carte
graphique.
212