Flame Maker – Etape 5 – Affichage via Swing

Swing est la bibliothèque standard pour réaliser des interfaces graphiques en Java, et elle se base sur une bibliothèque plus ancienne nommée AWT (pour Abstract Window Toolkit). Ces deux bibliothèques sont assez grosses et complexes, et leur organisation laisse malheureusement parfois à désirer pour des raisons historiques.

Seules les notions de base nécessaires au projet sont présentées ici. Une bonne source d'information complémentaire est The Swing Tutorial (en anglais). Des références vers les parties pertinentes de ce texte sont données plus bas.

Une interface Swing est composée d'un certain nombre d'éléments, nommés composants (components), qui ont pour la plupart une représentation graphique et avec lesquels il est parfois possible d'interagir. Par exemple, les fenêtres, les menus, les listes déroulantes, les boutons, les champs textuels, etc. sont des composants. Dans Swing, les composants sont généralement modélisés par des classes qui héritent de la classe JComponent.

Swing offre un certain nombre de composants prédéfinis, comme ceux mentionnés dans le paragraphe précédent. Mais il est également possible d'en définir de nouveaux en héritant de la classe JComponent et en redéfinissant un certain nombre de méthodes.

Les composants d'une interface sont organisés de manière hiérarchique, dans ce qu'on appelle en anglais la containment hierarchy. C'est-à-dire qu'il existe certains composants de base, principalement les fenêtres, qui peuvent contenir d'autres composants. Ces composants peuvent à leur tour en contenir d'autres, et ainsi de suite jusqu'aux composants terminaux.

On distingue donc généralement deux types de composants :

1. Les conteneurs (containers), dont le but principal est de contenir d'autres composants. Généralement, leur représentation graphique est très simple voire inexistante. Les fenêtres sont un exemple de conteneur, un autre est le panneau (panel ou parfois pane), modélisé par la classe JPanel, très utilisé pour organiser les interfaces mais souvent invisible à l'écran car dénué de représentation graphique propre.
2. Les composants terminaux, qui ne peuvent pas en contenir d'autres et qui terminent donc la hiérarchie. On les nomme parfois « feuilles » car ils se situent aux feuilles de l'arbre que forme la hiérarchie. Ces composants terminaux ont généralement une représentation graphique et il est parfois possible d'interagir avec eux. Les boutons sont un exemple de composant terminal, un autre est l'étiquette (label), modélisée par la classe JLabel.

Les conteneurs possèdent entre autres une méthode, add, qui permet de leur ajouter des composants fils. La position de ces composants dans le conteneur est déterminée de manière automatique par un gestionnaire de mise en page, décrit ci-dessous.

Référence : Using Top-Level Containers

A chaque conteneur est attaché un gestionnaire de mise en page (layout manager), qui se charge de placer et de dimensionner les composants du conteneur dans celui-ci. Chaque gestionnaire de mise en page a une stratégie de placement des composants qui lui est propre. Ainsi, certains gestionnaires sont très simples et se contentent de placer les composants côte-à-côte, tandis que d'autres sont plus complexes et placent les composants de manière à satisfaire certaines contraintes.

Avec Swing, les gestionnaires de mise en page implémentent l'interface LayoutManager. Pour cette étape, vous utiliserez deux gestionnaires de mise en page concrets, BorderLayout et GridLayout.

Références : A Visual Guide to Layout Managers et Using Layout Managers.

Certains conteneurs — en particulier les panneaux (JPanel) — peuvent être ornés d'une bordure. Il existe plusieurs sortes de bordures, mais les classes qui les modélisent implémentent toutes l'interface Border. On attache une bordure à un conteneur en appelant sa méthode setBorder, qui prend la bordure en argument.

Une particularité des bordures est que l'on ne les créé pas au moyen d'un énoncé new. Au lieu de cela, on passe par des méthodes de construction, qui sont des méthodes statiques de la classe BorderFactory. Par exemple, pour obtenir une bordure avec le titre Fractale du même genre que celle qui entoure la fractale dans notre programme, puis pour l'attacher au panneau fracPanel, on procède ainsi :

JPanel fracPanel = /* ... */;
Border fracBorder = BorderFactory.createTitledBorder("Fractale");
fracPanel.setBorder(fracBorder);

A noter qu'en dépit de la similarité des noms, il n'y a aucun rapport entre les bordures modélisées par l'interface Border et le gestionnaire de mise en page BorderLayout.

Référence : How to Use Borders

Le programme principal, qui se charge de construire et démarrer l'interface utilisateur, est modélisé par les deux classes suivantes :

• FlameMaker, qui est la classe principale du programme, c-à-d celle qui contient la méthode main.
• FlameMakerGUI, qui contient la totalité du code de l'interface utilisateur graphique (graphical user interface ou GUI en anglais).

Comme toutes les classes et interfaces de cette étape, ces deux classes appartiennent au paquetage ch.epfl.flamemaker.gui. Leur fonctionnement exact est détaillé ci-dessous.

La classe FlameMaker ne contient rien d'autre que la méthode principale du programme, main. Cette méthode crée une instance de la classe FlameMakerGUI puis appelle sa méthode start afin de construire et démarrer l'interface utilisateur.

Pour une raison qui ne sera pas détaillée ici¹, l'appel à cette méthode start ne peut se faire directement depuis la méthode main : il faut passer par un objet de type Runnable que l'on fournit à la méthode invokeLater de Swing. La méthode main a donc la forme suivante :

public static void main(String[] args) {
    javax.swing.SwingUtilities.invokeLater(new Runnable() {
            public void run() {
                new FlameMakerGUI().start();
            }
        });
}

La classe FlameMakerGUI représente l'interface graphique du programme. Elle possède entre autres des champs privés contenant l'état du programme, à savoir : le bâtisseur de fractale (de type Flame.Builder), la couleur de fond, la palette, le cadre de dessin et la densité. Pour l'instant, tous ces champs sont initialisés avec des valeurs par défaut que vous êtes libres de choisir. Les copies d'écran données dans les énoncés ont été obtenues avec un bâtisseur pour la fractale Shark Fin, un fond noir, une palette interpolant entre le rouge, le vert et le bleu, le cadre centré en (-0.25,0) de largeur 5 et hauteur 4, et une densité de 50.

La classe FlameMakerGUI possède de plus la méthode start mentionnée plus haut, qui construit et démarre l'interface graphique. Son fonctionnement est décrit dans les sections suivantes.

Swing offre un certain nombre de composants standards, mais il n'en existe évidemment aucun permettant d'afficher une fractale Flame ou un ensemble de transformations affines. Le second but de cette étape est donc d'écrire ces deux composants, puis de les placer dans les panneaux construits précédemment.

Chacun de ces composants est défini dans une sous-classe de JComponent. Cette classe possède un très grand nombre de méthodes, mais seules quelques-unes sont utiles ici, comme getWidth et getHeight qui permettent d'obtenir les dimensions du composant.

Certaines des méthodes de JComponent doivent être redéfinies dans les sous-classes pour mettre en œuvre le comportement spécifique du composant. Pour cette étape, les deux méthodes à redéfinir sont :

• Dimension getPreferredSize(), qui retourne la dimension idéale pour le composant. Cette taille est utilisée par certains gestionnaires de mise en page (malheureusement pas tous) afin de s'assurer que le conteneur a une taille suffisante. Vous pouvez par exemple retourner une dimension de 200 par 100.
• void paintComponent(Graphics g0), qui est appelée par Swing chaque fois que le composant doit être redessiné, p.ex. suite à un redimensionnement. L'argument de cette méthode est le contexte graphique, grâce auquel il est possible d'effectuer le dessin. Pour des raisons historiques, cet argument est déclaré comme ayant le type Graphics, mais en réalité la valeur passée est toujours de type Graphics2D, type qui offre beaucoup plus de méthodes que Graphics. Une méthode paintComponent typique commence donc généralement par faire un transtypage de cette valeur vers le type Graphics2D.

Le gros du travail pour terminer cette étape est donc d'écrire les méthodes paintComponent des deux composants spécifiques au projet. Notez que le système de coordonnées des composants a son origine dans le coin haut-gauche, et que l'axe des ordonnées est dirigé vers le bas.

Le premier composant à réaliser, nommé p.ex. FlameBuilderPreviewComponent, est celui affichant la fractale en cours d'édition.

Le constructeur de ce composant prend en argument toutes les données nécessaires au dessin de la fractale, à savoir : le bâtisseur de la fractale, la couleur de fond, la palette, le cadre et la densité. A noter que la raison pour laquelle on passe le bâtisseur de fractale et pas la fractale elle-même à ce composant deviendra claire lors des étapes suivantes.

Le dessin de la fractale se fait dans la méthode paintComponent. On utilise pour cela une technique très similaire à celle de l'étape précédente. La différence est qu'au lieu de produire un fichier, il faut produire une image qu'on affiche ensuite dans le composant.

La production d'une image est simple : il faut commencer par créer une instance de la classe BufferedImage au moyen du constructeur prenant en arguments la taille de l'image et son type. Pour ce dernier, on utilise la constante TYPE_INT_RGB, qui déclare que chaque pixel de l'image est représenté par un entier de type int contenant les trois composantes couleur, encodées selon la technique décrite dans l'étape précédente. Une fois l'image créée, la couleur de chaque pixel peut être définie au moyen de la méthode setRGB. Lorsque tous les pixels de l'image ont été définis, celle-ci est prête à être affichée dans le composant Swing. Cela se fait aisément au moyen de la méthode drawImage de Graphics (en passant null comme observateur).

Une question qui se pose est de savoir quelle taille utiliser pour l'image. Idéalement, on aimerait qu'elle occupe la totalité du composant, donc lui donner la même taille que ce dernier semble être une bonne idée. Toutefois, en faisant cela, on risque de déformer passablement la fractale, le rapport largeur/hauteur du composant n'étant pas forcément le même que celui du cadre passé au constructeur.

Pour éviter ce problème et dessiner une fractale non déformée, deux solutions existent : soit on réduit la taille de l'image pour qu'elle ait le même rapport largeur/hauteur que le cadre reçu ; soit on augmente la taille du cadre pour qu'il ait le même rapport largeur/hauteur que le composant (et l'image). Cette seconde solution est préférable, car c'est celle qui utilise au mieux la surface du composant tout en garantissant que la totalité de la zone du plan couverte par le cadre est visible. Elle est aisée à mettre en œuvre au moyen de la méthode expandToAspectRatio de la classe Rectangle.

Le second composant à réaliser, nommé p.ex. AffineTransformationsComponent, est celui affichant les composantes affines des transformations Flame caractérisant la fractale.

Le constructeur de ce composant prend en argument le bâtisseur de la fractale et le cadre. Ce dernier est adapté de la même manière que pour le composant précédent. Cela garantit que si les deux composants ont la même taille et reçoivent le même cadre en argument alors ils afficheront exactement la même zone du plan.

Le composant des transformations affines met en évidence l'une des transformations affine, en la représentant en rouge. Pour ce faire, il possède un attribut, nommé p.ex. highlightedTransformationIndex, qui donne l'index de la transformation à mettre en évidence. Le composant est équipé de méthodes permettant de lire et de définir cet attribut.

Il va de soi que lorsque la valeur de cet attribut change, le composant doit être redessiné. Pour demander à ce qu'un composant soit redessiné, il suffit d'appeler sa méthode repaint et Swing se charge du reste.

Pour faciliter la réalisation de ce composant, il est recommandé de travailler dans le système de coordonnées du plan et de ne passer à celui du composant qu'au moment du dessin. Comme d'habitude, ce changement de coordonnées peut être représenté au moyen d'une transformation affine.

Le dessin de ce composant est consitué exclusivement de lignes. Pour les dessiner, on utilise d'abord la méthode setColor du contexte graphique pour définir la couleur de dessin, puis la méthode draw à qui on passe une instance de Line2D.Double. Attention, vous manipulez ici des couleurs AWT, c-à-d des instances de java.awt.Color. Prenez garde à bien importer cette classe Color là, et pas celle que vous avez développée pour l'étape précédente, inutile ici !