Ergonomie de l'application :

Dans cette première étape l'interaction avec l'utilisateur concerne principalement l'attribution sémique sur les entités textuelles et la visualisation des isotopies ainsi générées. Les choix effectués sont les suivants :

• Une attribution sémique -- même si pour le moment elle reste triviale -- doit respecter les principes d'un positionnement intertextuel. Par exemple, une lexie ne peut pas avoir un trait sémantique si elle n'est pas située dans un texte, situé à son tour dans une anagnose.

  Nous avons donc choisi de mettre en place une contextualisation qui demande l'une après l'autre :

  1.

  la détermination de l'anagnose (dans l'inter-anagnose),

  2.

  celle du texte (dans l'intra-anagnose) et

  3.

  celle de la lexie (dans l'intratexte)

  avant de permettre l'attribution sémique sur une lexie. Bien sûr, si l'anagnose et le texte ont déjà été sélectionnés, alors les attributions peuvent se faire directement sur les lexies.

• Les entités textuelles (lexie, texte, anagnose, inter-anagnose) sont traitées de manière uniforme en tant qu'objets qui ont un nom dans une entité englobante et une représentation interne dans une fenêtre de texte. Par exemple, la chaîne de caractères Salut de Mallarmé peut être le nom du sonnet dans une anagnose. Et dans la fenêtre de texte contenant effectivement le sonnet (c.-à-d. sa représentation interne) nous pouvons identifier les noms d'un ensemble de lexies : Salut, Rien, écume, vierge, etc.

  Un même type de fenêtre de texte est implanté pour les textes, les anagnoses et l'inter-anagnose (racine de la hiérarchie ou ${\cal A}$). Le type de l'entité que la fenêtre contient apparaît sur le titre de la fenêtre.

Ce principe de positionnement textuel d'une entité dans une entité englobante, engendre pour une interface graphique utilisateur, le besoin fondamental de pouvoir gérer des chaînes de caractères comme des << entités positionnées >>, c.-à-d. comme des objets avec des caractéristiques propres qui puissent réagir aux actions de l'utilisateur. Par exemple :

• Si l'utilisateur clique avec la souris sur un texte positionné (e.g.<< Salut de Mallarmé >>) d'une anagnose, alors la fenêtre contenant ce texte positionné doit s'ouvrir.
• Si un utilisateur veut vérifier la distribution syntagmatique des lexies positionnées comprenant le trait sémantique /navigation/ dans un poème de Mallarmé il faut que l'application puisse facilement modifier leur présentation visuelle, e.g. en modifiant leur couleur.
• S'il efface un texte d'une anagnose, les positions des autres textes qui suivent doivent efficacement se mettre à jour.

Le mécanisme des tags, implanté dans l'interface graphique Tcl/Tk^5.5, est très bien adapté pour ce type de fonctionnement. Il offre la possibilité de définir des chaînes de caractères ou de listes de chaînes de caractères et ensuite s'y référer à l'aide d'un nom.

Les tags ont quelques propriétés très utiles pour les besoins présentés plus haut :

• un tag s'adapte automatiquement aux modifications dans le texte où il est situé.

  Nous pouvons ainsi ajouter une chaîne de caractères au milieu d'un tel texte sans avoir à modifier manuellement les positions de tous les tags qui suivent : Tk modifie automatiquement la position de tous les tags

• Tk donne la possibilité de modifier dynamiquement (i.e. en cours d'exécution) le style de la présentation visuelle de toutes les chaînes de caractères associées à un tag, e.g. modifier la couleur, mettre les caractères en italique, etc.
• plusieurs tags peuvent être composés en de listes plus étendues : e.g. pour présenter ensemble les lexies positionnées concernées par les traits /banquet/ ou /navigation/
• un tag a des réflexes et il peut ainsi engendrer des actions en réponse des événements issus de l'utilisateur. Par exemple, en cas de double-clic sur le tag d'un texte positionné, nous pouvons associer une fonction qui appelle la méthode qui ouvre une fenêtre avec le contenu du texte.

  Cette possibilité allège le code des méthodes en déléguant la responsabilité de ces appels à des mécanismes déjà implantés dans le langage.

Ainsi, si le nom d'un tag est associé à l'objet correspondant à l'entité positionnée, une action sur le tag peut être envoyée vers l'entité correspondante et vice versa.

Outre cette fonctionnalité très intéressante, Tcl/Tk offre quelques autres avantages :

• la création d'une interface graphique en Tcl/Tk est très rapide, du moins pour des interfaces relativement simples (par opposition à des interfaces graphiques telles que Xmotif) : un bon ensemble de responsabilités sont prises en compte de manière automatique par le langage. À titre d'exemple, le code suivant :

  frame .f
  text .f.t
  button .f.b -text "Sortir" -command exit
  pack .f.t .f.b .f
  

  suffit pour ouvrir une fenêtre de texte (avec les fonctionnalités copier/coller) avec un bouton en bas : si l'on y clique, le programme s'arrête (cf. fig. 5.3).

  
  

    

  Figure 5.3: Démonstration d'une fenêtre de texte (avec les fonctionnalités principales d'édition), avec un bouton de sortie, programmée à l'aide de quatre lignes de code en Tcl/Tk

  
  
  
• Tcl (et donc Tk qui est construit sur Tcl) est un langage interprété. Ceci donne la flexibilité d'un test en ligne, e.g. en interrogeant pendant l'exécution la valeur des chaînes de caractères associés à un tag, ou en ouvrant une nouvelle fenêtre pour les visualiser

Malgré sa bonne adéquation à de besoins d'interfaçage graphique, Tcl/Tk a un grand inconvénient par rapport au reste du système : elle ne suit pas la philosophie d'un langage orienté objet. Il existe plusieurs extensions orientées objet du langage Tcl lui-même mais peu de versions orientées objet de Tk, ce qui permettrait de pouvoir programmer en C++ et se servir des fonctionnalités de Tk dans un cadre homogène de programmation orientée objet.

 Nous avons préféré Hush 2.0 de Anton Eliëns [19], [21], [20], une transcription objet qui contient les principales caractéristiques de Tk dont nous avions besoin (mécanisme de tags, listes graphiques, fenêtre de textes) et qui permet l'accès direct à Tk, au cas où une certaine fonctionnalité n'est pas transcrite (e.g. filechooser). Un autre critère derrière ce choix a été l'évolution promise par une équipe de développement qui faisait souvent des mises à jour^5.6.

Après cette rapide présentation de quelques aspects techniques de la première réalisation pilote de l'application, nous allons maintenant effectuer quelques remarques issues de l'utilisation de ce prototype. Elles permettront de justifier les modifications et d'introduire l'évolution vers le deuxième cycle du développement. La nouvelle conception sera présentée en détail à partir de la p..