Travaux Pratiques Java/Swing

Liens et rappels

• API Java Standard Edition 6
• Site Java de Sun / Oracle
• Tutoriels Sun (index)
• Page de sites Java

Compilation

• Les programmes Java doivent être compilés au moyen de la commande javac
• Les fichiers avec l'extension .java sont les fichiers sources
• Les fichiers .class sont les fichiers résultant de la compilation

Remarques

• La variable $CLASSPATH de votre environnement Unix spécifie (si elle est définie) les répertoires où Java va chercher les classes. En cas de problème, rendre cette variable indéfinie à l'aide de la commande Unix : unset CLASSPATH
• l'option -class du compilateur (et de l'interpréteur) permet également de spécifier des répertoires de classes Java. Cette option écrase les spécifications de la variable $CLASSPATH.
• l'option -version affiche la version de l'environnement d'execution et d'autres informations utiles.

Exécution

Les fichiers .class sont des bytecodes qui ne sont exécutables que par la machine virtuelle Java (ils ne sont pas directement exécutables sous Unix). Il faut donc explicitement utiliser l'interpréteur java de la manière suivante:

    java  MonFichier   (sans l'extension .class)

Pour trouver les erreurs, on peut utiliser jdb, le debogueur Java. Des IDEs comme Eclipse faciliteront grandement l'édition et la mise au point du code.

Autres remarques

• Toutes les applications doivent comporter une méthode main() qui a le même role qu'en C ou en C++ (sauf les applets qui doivent posséder une méthode init()).
• Un fichier MonProgramme.java doit contenir une seule classe publique et celle-ci doit obligatoirement avoir le même nom que le fichier
• Ce fichier pourra également contenir d'autres classes à condition qu'elles ne soient pas publiques. Dans ce cas, le compilateur javac produira autant de fichiers .class qu'il y a de classes dans le fichier .java.

Exemples et exercices

Créer un nouveau répertoire et y copier les fichiers sources se trouvant dans ce fichier zip (NOTE: attention à ne pas écraser vos propres fichiers source si vous rechargez ce fichier zip par la suite !)

Bases de l'interaction: Boutons et Listeners

Le programme BipBip.java montre une interface graphique minimale (un bouton qui emet un "bip" et affiche un message quand on clique dessus). Exécutez ce programme (voir "Mode d'Emploi" ci-dessus pour la compilation et l'exécution), puis regardez le code source et les commentaires qui suivent.

La classe BibBip

Le fichier BipBip.java définit une classe unique BipBip qui a le même nom que le fichier à l'extension près. Cette classe doit obligatoirement être publique (voir "Quelques remarques sur les programmes Java").

BipBip est une sous-classe de JFrame, la classe Java Swing qui sert à contruire la fenêtre principale d'une application. Les objects graphiques doivent être ajoutés au JFrame (ou plus exactement à son contentPane: noter qu'avec les versions anciennes de Swing il faut le faire explicitement via la fonction getContentPane())

BipBip implémente l'interface ActionListener. C'est ce qui permettra de gérer le comportement du bouton comme on le verra ci-après (noter que le terme interface fait ici référence aux interfaces de programmation, pas aux interfaces graphiques !)

La classe BipBip définit trois méthodes détaillées ci-après. On remarquera en passant que les méthodes peuvent être définies (et appelées) dans n'importe quel ordre en Java (contrairement au langage C où il faut théoriquement déclarer les fonctions (i.e. spécifier leur signature) avant de les appeler).

La méthode main()

Tout programme Java doit obligatoirement définir une méthode main() qui sert de point d'entrée à l'éxecution du programme (à la différence des Applets qui doivent définir la méthode init()). Cette méthode doit être public static (static signifie que c'est une méthode de classe et non d'instance).

main() instancie la classe "BibBip", ce qui a pour effet de créer l'interface graphique. Cette instance est le composant graphique de plus haut niveau de l'application et "contient" donc les autres composants graphiques. En d'autres termes, cette instance est la racine de l'arbre d'instanciation de la GUI.

Il faut enfin calculer la disposition spatiale des de composants graphiques puis les rendre visible. Ceci ce fait en appelant les méthodes pack() et show() sur l'objet de plus haut niveau.

La méthode BibBip()

C'est le constructeur de la classe BibBip. Cette méthode:

• crée une instance de JButton

• ajoute ce bouton au conteneur via la méthode add().
  Noter que add() est une méthode du conteneur qui a d'autres signatures possibles (que l'on verra dans les exemples suivants).

• ajoute un ActionListener à ce bouton au moyen de la méthode addActionListener(). Cet ActionListener possède une méthode actionPerformed qui sera automatiquement appelée chaque fois que l'on cliquera sur le bouton. Les méthodes des Listeners jouent dont le rôle des fonctions de call-back dans les langages non orientés objet (par exemple le toolkit Motif en langage C).

Remarque:

Quasiment tous les composants graphiques Java doivent avoir un parent (à part JFrame, etc.) pour apparaître et fonctionner correctement. Ceci est généralement fait via la méthode add() du parent. N'oubliez donc pas cette étape (vous pourriez obtenir des résultats etranges ou des NullPointerException dans le cas contraire).

La méthode actionPerformed()

Cette méthode est appelée chaque fois que l'on clique sur le bouton. Elle est héritée de l'interface ActionListener. que la classe BibBip "implémente". Le code montre comment afficher un message sur le Terminal (l'équivalent du printf() du C) et émettre un bip.

Gérer plusieurs widgets (comportement et présentation)

L'exemple LesBoutons.java montre une manière élémentaire de disposer plusieurs widgets dans un Container et de gérer leur comportement. On remarquera que:

• Au debut du constructeur, on fait appel à la fonction setLayout pour attacher un Layout Manager adéquat au contentPane du JFrame. La gestion de la disposition des composants graphiques n'est pas effectuée par le conteneur lui-même mais par un objet associé: un Layout Manager. A chaque type de conteneur est associé un Layout manager par défaut (voir la doc.) qui peut être changé via la méthode setLayout().
  Dans cet exemple, on utilise un FlowLayout qui a pour effet de mettre tous les enfants à la suite.

• Tous les boutons sont associés au même ActionListener, qui n'est autre que l'objet LesBoutons lui-même dans cet exemple. Par consequent, la même méthode actionPerformed() sera appelée quel que soit l'objet activé (ie. cliqué).

• Pour savoir quel bouton a été cliqué dans actionPerformed() on peut tester la valeur renvoyée par getSource() (méthode de l'ActionEvent) qui indique la "source" qui a provoqué l'événement (c'est-à-dire un des 3 boutons dans notre cas).

• D'autre part, getActionCommand() (méthode de l'ActionEvent) renvoie une chaîne de caractères (type String) qui contient par défaut le nom du bouton. Cette chaîne peut également être utilisée pour identifier le bouton activé. Elle peut être changée si nécéssaire par la méthode setActionCommand().

Exercice

Associer les comportements suivants aux 3 boutons :

• le bouton de gauche échange la couleur du fond (le "background") et celle des caractères (le "foreground") du JLabel. Deux activations successives du bouton permettront donc de retourner à l'état initial.

• le bouton du milieu échange la sensitivité du bouton de gauche c-a-d le fait qu'il soit activable ("enabled" en jargon Java) ou non (auquel cas il apparaîtra en grisé).

• le bouton de droite termine le programme (voir la classe lang.System).

Indications: consulter les méthodes des classes en question dans le manuel de référence. Pensez à utiliser la fonctionnalité "Find in Page" (ou similaire) de Netscape, Mozilla ou IExplorer pour retrouver les méthodes dans les pages décrivant les classes Java).

BorderLayout et composants élémentaires

L'exemple LesComponents.java introduit quelques-uns des composants Swing les plus courants et montre l'utilisation du LayoutManager BorderLayout.

Cette GUI comprend 2 conteneurs intermédiaires (de classe JPanel). Ces conteneurs sont internes et peuvent être emboîtés entre-eux (il ne créent pas de nouvelle fenêtre contrairement aux JFrames, et aux JDialogs que nous verrons ensuite). Leur Layout Manager par défaut est FlowLayout (enfants mis à la suite, passage à la ligne quand il n'y a plus de place).

Cet exemple introduit un nouveau Layout Manager nommé BorderLayout. Celui-ci impose une disposition spatiale de type points cardinaux. Les enfants sont ajoutés au conteneur associé au moyen d'une forme particulière de la méthode add() qui permet de spécifier leur emplacement. Par exemple:

         add(BorderLayout.NORTH, panel1);

Il est à noter que BorderLayout ne retaille pas tous les enfants de la même manière quand on retaille la fenêtre. Faites un essai : que constate t-on ?

Remarque: le LayoutManager par défaut du contentPane est déjà BorderLayout. La ligne: contentPane.setLayout(new BorderLayout()) est donc optionnelle dans ce cas.

Cet exemple introduit également les objets JTextField (une ligne de texte), JTextArea (une zone de texte multi-lignes) et JCheckBox (un bouton à états ; attention au "B" majuscule !)

Les trois check boxes crées dans cet exemple sont stockés dans un tableau qui est lui-même créé au début du programme:

         JCheckBox[] checkboxes = new JCheckBox[3];

Il est important de noter que cette ligne initialise le tableau mais pas les éléments contenus !. En d'autres termes, on crée un tableau de 3 éléments dont chaque élément "pointe" sur null (c'est-à-dire sur aucun objet). Chaque élément du tableau est initialisé ultérieurement lorsque l'on crée les check boxes :

         checkboxes[0] = new JCheckBox("Oui", true);
         ...etc...

Remarque: la définition:

         Checkbox[] checkboxes;

ne serait pas valide en C ou en C++. Pour les nostaliques, Java permet également d'écrire:

         Checkbox checkboxes[]; 

Le programme définit enfin la méthode actionPerformed qui est appelée quand on clique sur le bouton Ok ou quand on frappe la touche ENTER sur le text field (on remarquera que c'est la même méthode du même listener qui est appelés dans les 2 cas bien que les classes soient différentes).

Exécuter ces actions et regarder le code source. Regarder également les messages affichés sur le Terminal (et en particulier la valeur de l'actionCommand).

Exercice

Compléter la méthode actionPerformed de telle sorte que l'état de chacun des trois check boxes (sélectionné / non sélectionné) s'affiche sur le JTextArea chaque fois que l'on active le JTextField ou le Button.

Remarque: on pourra faire cet exercice en récupérant l'état courant des 3 check boxes (voir la doc. et méthodes isSelected(), getSelected()). Il ne sera pas nécessaire de leur ajouter un ActionListener dans ce cas de figure.

GridLayout, RadioButtons et ScrollPanes

Le programme MaRadio.java reprend l'exemple précédent en introduisant le Layout Manager GridLayout et en montrant comment utiliser des RadioButtons (c'est-à-dire des check boxes exclusifs).

Ces RadioButtons :

• sont rendus exclusifs au moyen d'un ButtonGroup
• sont inclus dans un JPanel auquel est associé un objet GridLayout. Ceci permet de définir une grille élastique matricielle où tous les composants ont toujours la même taille.

Retailler la fenêtre. Que constate t-on ? Noter que le JTextArea et les JPanels ne sont pas agencés de la même faÁon que dans l'exemple précédent par rapport au BorderLayout du JFrame.

Cet exemple montre donc comment on peut emboîter plusieurs conteneurs avec des LayoutManagers différents pour obtenir des changements de taille appropriés lorsque l'on retaille la fenêtre.

Le programme MaRadio.java montre enfin comment utiliser des boucles et des tableaux pour simplifier et compacifier l'écriture du code.

Exercice

Si l'on clique de nombreuses fois sur les radio buttons, on constatera un comportement qui peut paraître étrange. Que se passe-t'il ? Pourquoi ?

Une solution pour éviter cet effet consisterait à utiliser des ascenceurs. C'est ce que l'on vous demande de faire en utilisant la classe JScrollPane.

Les Boîtes de Dialogue

La classe JDialog permet de créer des fenêtres secondaires, c'est-à-dire des boîtes de dialogue. Un JDialog ressemble à un JFrame, mais avec quelques particularités. Tout d'abord les JDialogs sont iconifiés et détruits en même temps que la fenetre principale. D'autre part, ils peuvent être rendus modaux (i.e. bloquants) au moyen de la méthode setModal().

Les JDialogs sont des fenêtres vides qu'il convient de compléter (de la même manière que les autres conteneurs Java). Swing permet également de créer des boîtes de dialogue prédéfinies au moyen des classes JFileChooser (pour choisir un fichier), JOptionPane (pour afficher un message) etc.

L'exemple LesDialogs1.java illustre ces différents aspects en reprenant des parties des exemples précédents. On regardera et vérifiera en particulier:

• comment la méthode actionPerformed ouvre ou ferme les JDialogs quand on clique sur les boutons Open et Close.

• que le second JDialog est bien modal (ce qui a pour effet de bloquer l'application puisque l'on n'a pas encore écrit le code pour fermer cette boîte de dialogue). Le bouton "Hide 2" ne sert donc à rien pour l'instant.

• qu'il est nécessaire d'exécuter la méthode pack() après avoir ajouté les enfants du JDialog (sinon ils n'apparaîtront pas).

Amélioration: programmation OO

Dans l'exemple précédent on programmé "à la mode C" : les boîtes de dialogue sont crées en appelant une méthode qui joue à peu près le même rÙle qu'une bête fonction C (noter que CreerMonDialog() est d'ailleurs une méthode de classe).

La logique de la programmation orientée objet voudrait plutÙt que l'on définisse une nouvelle classe (qui hérite de JDialog) pour pouvoir créer proprement les boîtes de dialogue. Cette faÁon de faire permet de décomposer un programme en sous-parties clairement identifiées, bien séparées et facilement réutilisables, au lieu d'aboutir à un gigantesque sac de noeuds au bout d'un certain temps de développement.

C'est ce que l'on se propose de faire dans le programme LesDialogs2.java.

Regarder le code correspondant à l'instantiation et à la définition de la nouvelle classe MonDialog. Celle-ci hérite de JDialog et implémente également ActionListener. Il est donc nécessaire de définir la méthode actionPerformed correspondante qui va permettre de coder le comportement des widgets contenus dans ce JDialog. Et ... c'est justement ce que l'on va vous demander de faire dans l'exercice suivant !

Remarques:

• il y a maintenant deux méthodes actionPerformed: une pour chaque classe. Ceci permet de bien séparer le traitement des composants graphiques des deux fenêtres.

• Noter que le constructeur de la classe MonDialog appelle explicitement celui de sa superclasse via une expression du type:

      super(frame, title, modal);  

  Ceci est nécessaire pour pouvoir spécifier quel constructeur de JDialog on veut utiliser (étant donné qu'il y en a plusieurs). Cet appel doit obligatoirement être la première instruction dans le constructeur.

• L'appel du constructeur de la superclasse est explicite dans cet exemple. Lorsqu'il n'y a pas d'appel explicite, celui-ci est fait implicitement. De fait tous les constructeurs de toutes les superclasses sont toujours appelés quand on crée un nouvel objet (et ce, dans l'ordre descendant).

Exercices

• les JDialogs se ferment lorsque l'on clique sur leur bouton OK
• que le texte entré dans leur JTextField soit ajouté au JTextArea de la fenêtre principale (comme c'était le cas dans le programme LesComponents). Ceci suppose de pouvoir faire communiquer harmonieusement ces deux objets.

2. Rajouter une troisième boîte de dialogue qui permettrait de sélectionner un nom de fichier et de l'afficher dans le JTextArea de la fenêtre principale (NB: utiliser JFileChooser).

Enrichissement d'objets Swing par héritage

Il est fréquent qu'une application nécessite l'utilisation d'objets ayant des fonctionnalités dont ne disposent pas les objets standard fournis dans les librairies Java. Plusieurs stratégies sont alors possibles:

• La stratégie "classique" consisterait à instancier l'objet standard puis à lui appliquer une fonction définie par ailleurs qui réaliserait la fonctionnalité souhaitée,

• La stratégie "objet" consiste à créer une nouvelle classe, qui hérite de la classe standard et à lui rajouter une méthode (ou à redéfinir une méthode existante) qui implémente cette fonctionnalité.

• de mieux mettre en évidence les relations entre objets et fonctions (et d'éviter ainsi des erreurs, les méthodes ne pouvant être appelées qu'avec les objets pour lesquelles elles sont effectivement définies)

• de redéfinir les méthodes : plusieurs classes peuvent avoir des méthodes ayant le même nom mais des impléméntations différentes sans qu'il ait d'ambuiguité

• de permettre aux méthodes d'instance d'accéder aux variables d'instance des objets auxquelles elles sont appliquées.

Nous allons illustrer cette approche en enrichissant les JButtons de telle sorte qu'ils affichent une bulle d'aide chaque fois que la souris entre dans le bouton (noter que cette fonctionnalité existe en standard mais nous allons la réimplémenter pour les besoins de l'exercice). Le programme TipProg.java montre comment définir une nouvelle classe de boutons, appelée TipButton (dans le fichier TipButton.java) qui effectue (partiellement) ce travail. Les TipButton ont exactement les mêmes fonctionnalités que les JButton standard, sauf que leur couleur change quand la souris passe dessus et un message d'aide est affiché dans la Terminal d'où on a lancé le programme.

Cet exemple, pour l'instant incomplet (le message devrait être affiché dans une bulle d'aide), illustre plusieurs aspects importants :

Héritage et enrichissement progressif

• On peut ajouter de nouvelles fonctionnalités sans avoir à modifier le code déjà existant. Par exemple, on n'a pas besoin de savoir comment JButton est écrit pour rajouter les fonctions qui nous intéressent. Cette possibilité d'"enrichessement progressif" est une propriété importante des langages à objets.

• L'objet TipButton est facilement utilisable dans d'autres programmes et peut lui-même être enrichi, d'où une "réutilisation" facilitée du code.

Surcharge

• De même que l'objet standard JButton, TipButton possède plusieurs constructeurs. Ces constructeurs permettent de créer un bouton "vide", ou bien avec un label, ou bien avec un label et un message d'aide. Cette possibilité de définir plusieurs méthodes avec le même nom pour une classe donnée s'appelle la surcharge (overloading en anglais). Cette possibilité est génerale et s'applique à toutes les méthodes et pas seulement aux constructeurs. (Note: ne pas confondre la surcharge avec la redéfinition de fonction (overriding en anglais), c'est-à-dire lorsqu'une méthode est redéfinie dans une sous-classe)

Constructeurs

• Le 2e constructeur de TipButton se contente d'appeler le 1er constructeur avec les arguments adéquats via le mot clé this. Ceci permet de réduire la duplication de code, fréquente source d'erreurs quand on modifie les programmes ultérieurement.

• Les deux autres constructeurs commencent tout d'abord par invoquer un des constructeur de la superclasse JButton avec les arguments adéquats via le mot-clé super. super doit obligatoirement figurer avant toute autre instruction. Si super est omis, il est implicitement ajouté par le compilateur (et appelé sans argument).

• En fait, les constructeurs de toutes les superclasses de TipButton sont appelés, soit implicitement, soit explictement via le mot clé super. Ces appels se font dans l'ordre descendant (de Object jusqu'à TipButton) : c'est ce que l'on appelle le chaînage des constructeurs.

Variables de Classe et d'Instance

• Les variables aide et backcolor de l'objet TipButton sont (et doivent être !) des variables d'instance. Ceci signifie que ces variables sont propres aux instances et peuvent donc avoir des valeurs différentes pour deux instances différentes de la même classe (deux boutons différents n'ont généralement pas la même aide !). Par défaut, toutes les variables sont des variables d'instance.

• Inversemement, les variables de classe, sont propres à une classe donnée et sont donc partagées par toutes les instances (= même valeur quelle que soit l'instance). Les variables de classes "existent toujours" et sont référenÁables même si aucune instance d'objet n'a été créée. Ces variables sont définies en ajoutant le mot-clé static devant leur type (ce mot-clé est un résurgence du langage C indiquant un stockage en mémoire dite "statique" ou "gobale")

Méthodes de Classe et d'Instance

• Les méthodes d'instance s'appliquent toujours à une instance. Elles possèdent un paramètre this caché qui leur permet de référencer l'objet sur lequel elles s'appliquent et d'accéder aux variables d'instance de cet objet.

• Inversement, les méthodes de classe s'utilisent comme des "fonctions classiques" d'un langage non objet. Elles ne s'appliquent pas à une instance, n'ont pas de paramètre caché 'this' et ne peuvent donc pas accéder aux variables d'instance des objets. Comme pour les variables, les déclarations des méthodes de classe commencent par le mot clé static.

Réutilisation de la classe TipButton

Pour rendre notre nouvel objet TipButton facilement réutilisable et accessible depuis n'importe quel programme, il est nécessaire de le rendre public et ddonc e le séparer de la classe TipProg en le mettant dans un fichier spécifique (noter qu'un même fichier java ne peut contenir qu'une seule classe publique).

La compilation de TipProg.java entrainera automatiquement celle de TipButton. Il suffira donc de faire :

        javac  TipProg.java
puis:
        java  TipProg

Exercices

• Complétez la classe TipButton de telle sorte qu'elle ouvre effectivement une bulle d'aide. Cette bulle sera réalisée à l'aide d'un JPopupMenu contenant un JLabel que l'on affichera quand la souris entrera dans le TipButton et que l'on fera disparaître quand elle en sortira.

  Ecrivez deux versions : d'abord en utilisant des variables d'instance puis des variables de classe. Quel est l'avantage de la 2eme solution ?

• De fait le toolkit Swing intègre déjà la fonctionnalité qui nous interesse dans cet exemple (les "tool tips") en standard (via la méthode setToolTipText(String) des JButtons, etc.) Modifiez la classe TipProg pour essayer cette fonctionnalité. Que constate-ton ?

Les Layout Managers

Les 3 Layout Managers les plus courants ont déjà été présentés au cours du TP précédent:

• FlowLayout : les widgets sont mis les uns à la suite des autres de gauche a droite, puis a la ligne suivante s'il n'y a plus d'espace disponible.

• BorderLayout : disposition de type "points cardinaux". Ajouter les widgets au conteneur correspondant en specifiant l'emplacement souhaite en premier argument de la methode add().

• GrigLayout : grille elastique ou toutes les cellules sont de meme taille. Les widgets sont attachés a ces cellules selon leur ordre de création, de gauche à roite et de haut en bas. On peut également specifier un ordonnancement particulier au moyen d'une forme appropriée de la méthode add().

• CardLayout : considere les widgets du conteneur associe comme une "pile de cartes" : un seul widget est visible à la fois et il occupe toute la surface de son conteneur,

• GridBagLaout : permet de spécifier des contraintes spatiales complexes à partir d'une grille élastique. A l'inverse de GridLayout les widgets peuvent occuper plusieurs cellules (i.e. tous les widgets ne sont pas forcement de la meme taille). Ces contraintes sont specifiées individuellement pour chaque widget via un object GridBagConstraints.

Graphique et Inner Classes

Le programme DesGribouillis1.java montre comment gérer des événements souris pour permettre de faire du dessin à main leveé. Ces programmes nécessitent de travailler avec les Listeners: MouseListener et MouseMotionListener. Contrairement à l'ActionListener vu dans les exemples précédents, ces deux Listeners possèdent plusieurs méthodes qu'il est donc nécessaire d'implémenter même si elle ne font rien (corps vide).

Le programme DesGribouillis2.java montre une version plus élégante du même programme en utilisant les classes imbriquées (inner classes). Ce programme contient deux types de classes imbriquées

• des classes imbriquées anomymes qui servent à associer les Event Listeners traitant les événements souris.
• des classes imbriquées nommés (BgButton, FgButton) qui servent à créer des boutons spécifiques qui permettront (respectivement) de changer la couleur de la zone de dessin ou celle du pinceau.

Exercice

Communication entre Applications

Cette section montre comment faire communiquer 2 applications distinctes par des sockets. Plus précisément, on va faire dialoguer:

• un programme Java qui va servir d'interface graphique (GUI)
• un programme C qui va servir de serveur de calcul pour cette GUI

Ce type d'architecture est tès général et peut être décliné sous diverses formes. Notre exemple (fichiers Client.java, serv.c et Makefile) montre un cas simple où les requêtes envoyées par le client sont traitées en séquence par le serveur. Des architectures plus complexes pourraient permettre de traiter des requêtes en parallèle.

Exercice

Compléter l'exemple de manière à réaliser une calculette:

• le client Java affichera la GUI de la calculette
• le serveur C effectuera les calculs et renvera les résultats à son client qui aura pour charge de les afficher

Note: la partie C doit être limitée au strict minimum (utiliser la fonction sscanf()).

Les Menus

Le programme LesMenus.java montre comment créer des barres de menus (JMenuBar) et des menus déroulants (JMenu). On notera en particulier que les boutons contenus dans les menus ne sont pas des boutons ordinaires mais des JMenuItem.

Exercice

Compléter le programme DesGribouillis2.java afin de produire une interface graphique complète, comportant:

• une barre de menu (et les menus associés),
• une "toolbar" (barre d'outils en dessous de la barre de menu)
• une "statusline" en bas de l'application
• des boîtes de dialogues (en particulier pour "ouvrir" ou "sauver" un fichier)
• une zone de dessin active

Les Applets

Les Applets sont des programmes Java qui sont exécutables depuis un navigateur Web. Ces programmes ont (entre-autres) pour particularité de ne pas posséder de méthode main() (laquelle est obligatoire pour tous les autres programmes Java). A la place, elles doivent comporter une méthodes init() qui sert à initialiser l'applet lorsqu'elle est chargée par le browser.

D'autre part, les Applets sont realisées en dérivant la classe JApplet (et non JFrame) comme pour les applications "normales"). Ceci s'explique par le fait que l'Applet est normalement inclue dans une page Web (JFrame ouvrirait une fenetre en dehors du navigateur Web).

Une applet est spécifée dans une page HTML de la manière suivante:

 <APPLET CODE = "MonApplet.class" CODEBASE="MesClasses" WIDTH=150 HEIGHT=25>
 </APPLET>

Les applets peuvent également être testées au moyen de commande appletviewer. Cette commande prend pour argument une page HTML (un fichier ou une URL)

Pour rendre le TP

1) Verifier que votre code compile et s'exécute correctement depuis une salle de TP Unix de l'Ecole.

2) Ecrire un bref fichier README indiquant les questions traitées et contenant les réponses aux questions et tous les commentaires que vous jugerez utiles. Ce fichier doit être en PDF ou en HTML (en UTF-8) ou au format texte (en UTF-8 également). N'oubliez pas de mettre votre nom (au moins dans le README et de préférence aussi dans les autres fichiers)

3) Créer un fichier zip ou tar.gz (pas d'autre format!) contenant votre README et le code source (ne mettez pas l'executable ni les .class)

4) Aller à l'URL http://services.infres.enst.fr/rendutp/, cliquer (le bon ;-) lien puis entrer votre nom et télécharger le fichier zip ou tar.gz

NB: seule la dernière version téléchargée est prise en compte