Sous-sections
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é).
stuf
2005-09-06