branch/noswap

Le support du mode "multi-palettes" dans LEDS m'a obligé à revoir un point assez noirâtre de mon moteur d'interface graphiques: les widgets dynamiques. Bon, c'est un peu pompeux de les appeler comme ça, j'avoue: il ne s'agit ni plus ni moins que de pouvoir cacher certains éléments à l'écran ou d'en modifier l'ordre de priorité au fil de l'exécution du programme. La barre de boutons qui apparaît et disparaît dans l'éditeur de niveaux, par exemple ...

La plupart du temps, je m'en sors avec un tableau dont je modifie l'emplacement final. Un bouton "undo" à faire apparaître ? nbWidgets++ ... il doit disparaître ? nbWidgets--. C'est aussi simple que ça. Dans le cas des boutons d'édition, c'est un peu plus subtil, parce que la "zone sensible" qui permet de construire le niveau couvre tout l'écran et qu'il n'y a pas moyen de "cliquer à-travers" pour toucher les nouveaux boutons. Jusqu'ici, je me servais alors de Windows::swap() qui permuttait deux widgets dans la liste d'affichage, mais cette façon de faire rend rapidement le code lourdaud et peu lisible, avec pas mal de bugs qui jouent à cache-cache dès qu'on essaie de changer quoi que ce soit.

C'était donc l'occasion d'essayer autre chose: des instructions de saut dans la table des "widgets". En clair, je peux maintenant avoir quelque chose comme

normal: (grille) (boutons) (palette) STOP
copie: (curseur) GOTO normal
recolor: (bouton sync) (bouton undo) GOTO normal

Je n'ai donc "plus qu'à" choisir le point d'entrée dans ma liste de widgets pour avoir le rendu souhaité. Note qu'heureusement, ce type de pratique était resté rare puisque j'ai la possibilité "d'empiler" des "fenêtres" justement pour éviter ce genre de manipulations. S'il n'y avait pas eu en plus la grande tambouille du changement de linker, je n'y aurais d'ailleurs probablement même pas consacré un post.