D.3 Les outils internes

La création de nouveaux outils internes reprend des principes proches de ceux des dispositifs d'interaction. La classe abstraite DMaggLiteComponentInnerTool fournit les mécanismes de base (slots communs, gestion du retour graphique, activation, mode et transmission des sorties, etc) et propose des méthodes abstraites pour réaliser les actions particulières à l'outil.

D.3.1 Exemple de l'outil interne de dessin

Le code Java suivant présente la structure de l'implémentation de l'outil interne de dessin: DMaggLiteDrawInnerTool.

Cet outil, en plus des slots par défaut gérés par la super classe (use, x et y), propose des slots particuliers pour gérer l'épaisseur et la couleur du trait (lignes 3 à 7).
Les méthodes doActivate et doDesactivate (lignes 17 et 22) permettent de réaliser les actions propres à l'outil lors de son activation et de sa désactivation.
Enfin, les méthodes suivantes sont invoquées par l'algorithme principal du dispositif abstrait, selon les entrées reçues et le mode d'utilisation de l'outil (local ou global):

• alwaysAction: cette méthode est appelée à chaque pas d'exécution, quelles que soient les valeurs des slots d'entrée;
• toolActionOutside(boolean use): actions à réaliser lorsque l'outil est en dehors des bornes graphiques du composant lié;
• toolActionNoXY(boolean use): actions à réaliser si il n'y a pas eu de mouvement de l'outil;
• toolAction(boolean use, Point2D localP, Point2D screenP): actions à réaliser si il y a eu mouvement de l'outil dans les bornes du composant. Les paramètres localP et screenP transmettent la position actuelle de l'outil en coordonnées locales au composant et en coordonnées écran;

Pour notre outil interne de dessin, la méthode alwaysAction va permettre de traiter à tout moment les entrées reçues par les slots particuliers à l'outil (taille et couleur).
La méthode toolAction va implémenter l'action de dessin sur le composant graphique associé à l'outil, accédé par la variable component. Notons que, contrairement aux dispositifs d'interaction, aucune vérification de compatibilité n'est faite au niveau de la super classe lors de l'association entre un objet graphique et un outil interne. C'est donc au niveau de l'implémentation de l'outil concret que doit être réalisée cette vérification (nous ne l'avons pas détaillé dans cet exemple de code par soucis de clarté).