Les commandes de TXM partagent une façon d'organiser leurs paramètres et de les présenter dans les éditeurs.

Une commande :

• a des paramètres
• les paramètres ont des valeurs par défaut lorsque qu'un résultat est créé
• les valeurs par défaut sont définis dans les préférences à plusieurs endroits
• la valeur par défaut du paramètre est résolue suivant un ordre hiérarchique dans les préférences

Les valeurs par défaut des paramètres d'une commande sont construites à partir :

1. si définies, de préférences de commande (Concordance, Index, Edition…)
2. de préférences (globales) de moteur (moteur de recherche, moteur de statistiques, moteur de graphiques…)

Exemple de parcours de résolution de la valeur par défaut du paramètre “police des labels” d'une AFC :

1. TXM recherche dans les préférences de la commande “AFC” (observable dans la page de préférence commune à la visualisation de tous les graphiques dans TXM\Avancé\Moteur de Graphiques)
   1. si la valeur est définie par l'utilisateur, elle est utilisée
   2. sinon TXM recherche dans les préférences globales du moteur (observable dans la page de préférence commune à la visualisation de tous les graphiques dans TXM\Utiilisateur\AFC)
      1. si la valeur est définie, elle est utilisée
      2. sinon le paramètre n'est pas initialisé

Depuis TXM 0.7.8 (voir Architecture des préférences TBX et RCP pour les détails techniques), la gestion des préférences et paramètres de commande tend vers le mécanisme suivant.

Les préférences des commandes de TXM sont définissables dans plusieurs scopes hiérarchiques et combinables, chaque sous-enfant pouvant redéfinir les préférences de son parent. Ceci est notamment implémenté dans le cas des résultats de type “Graphique” mais devrait a priori s'étendre à d'autres moteurs ou couches logiques.

• préférence par défaut globale, partagée par toutes les commandes (eg. page de préférence commune à la visualisation de tous les graphiques dans TXM\Avancé\Moteur de Graphiques)
• préférence par défaut dédiée à une commande (eg. TXM\Utilisateur\AFC\Rendu des graphiques qui remplace et spécifie la préférence équivalente globale)
• préférence locale à l'éditeur (barre d'outils rétractable masquée par défaut et accessible via le bouton “Afficher/Masquer les paramètres de rendu”. On parlera ici plutôt de paramètre. Ces paramètres sont persistés dans le TXMResult

Toutes ces préférences sont définies dans les plugins dits “core” de TXM afin d'être persistées au niveau de la couche non UI et notamment pour être partagées avec le portail TXM.

Exemple technique de parcours de résolution de la valeur du paramètre “police des labels” d'une AFC. La recherche s'arrête dès qu'une valeur est trouvée en parcourant les noeuds de préférences Eclipse dans l'ordre suivant :

1. TXMResult : scope “projet du corpus” , noeud “identifiant du TXMResult”
2. valeur dans le noeud de préférence de la commande AFC : scope instance, noeud “identifiant du Bundle”
3. valeur dans le noeud de préférence de la commande AFC : scope default, noeud “identifiant du Bundle”
4. valeur dans le noeud de préférence de la commande Moteur : scope instance, noeud “identifiant du Bundle du Moteur”
5. valeur dans le noeud de préférence de la commande Moteur : scope default, noeud “identifiant du Bundle du Moteur”

Les Scopes de préférences Eclipse:

• Les valeurs du scope “default” sont définis dans le code de TXM et livrée dans une installation de TXM
• Les valeurs du scope “instance” sont définis par l'utilisateur dans les pages de préférences
• Les valeurs des scope “projets” sont définis lors de la persistance des résultats (lors d'un compute et la fermeture de TXM)

classe “TXMPreferences” de TXM (à completer&préciser):

• getInstance() → évite de redonner le noeud RCP
• getters&setters String, int, float etc.
• déclarations des champs
• initialisations des champs
• héritage ou pas de l'initialisation de la classe parente
• héritage multiple par composition de préférence avec un noeud “alternatif”

Le fonctionnement dans la 0.8.0

A la création d'un résultat, il n'est pas encore calculé. Avant tout calcul, ses paramètres sont initialisés avec les préférences.

À la création d'un résultat :

• un noeud de préférence Eclipse dédié au résultat est créé pour stocker ses paramètres (un sous-noeud du scope projet)
• un lien est fait vers le noeud de préférence de la commande qui contient les valeurs courantes et les valeurs par défaut : bundle_id, ex. “org.txm.core.concordance”
• une liste d'éventuels noeuds de préférences alternatifs peut être donnée (ex. pour les moteurs)
• des méthodes sont appelées pour charger semi-automatiquement les valeurs des paramètres de l'objet en fonction d'une liste de noms de paramètres définis grâce aux Annotations Java définies en dur dans l'objet. Lors de la recherche de paramètres :
  • le résultat est nouveau, son noeud de préférence n'a pas valeur de paramètre de commande
  • si une préférence existe dans le noeud de préférence de la commande, sa valeur courante est chargée
  • sinon si une préférence existe dans les noeud de préférence alternatifs, sa valeur courante est chargée
  • sinon la valeur par défaut de la préférence est chargé depuis le noeud de préférence de la commande

Lors du calcul/compute d'un résultat :

• une fois les paramètres réglés correctement et validés par le TXMResult, le calcul peut être lancé
• une fois le calcul terminé correctement, les paramètres sont stockés dans le noeud de préférence du résultat
• les préférences du noeud sont flushés dans un fichier .prefs. Ceci permet à la persistance entre sessions de TXM ou de partage de résultat entre instances de TXM.

À l'ouverture d'un résultat :

• L'appel d'une commande RCP va ouvrir un éditeur en lui donnant un résultat non calculé (l'utilisateur n'a pas encore modifié les paramètres en plus de ceux initialisés par les préférences au niveau core)
  • l'éditeur va charger semi-automatiquement les valeurs de ses Widgets une jointure réalisée par le champ “key” des Annotations Java attachés aux widgets et aux paramètres du résultat
    • il pourra donc s'agir des préférences par défaut de la commande, d'un noeud alternatif, ou bien des paramètres locaux du résultat
• au clic sur le bouton calculer/compute, les valeurs des Widgets de l'éditeur sont transmises semi-automatiquement via Annotations en tant que paramètres du résultat

• Il faut définir pour les paramètres et préférences : les paramètres et préférences qui peuvent être partagés entre fonctionnalité.

[SJ, en cours, TXM 0.8.0, 2019-10-30] hiérarchie actuelle des paramètres héritées :

• ChartsEngine, noeud alternatif [show_title, show_legend, show_grid, colors_mode, font, multiple_line_strokes]
  • Commandes cherchant dans le noeud supérieur : AFC, Classification, Partition, Progression, Spécificités, TextBalance, WordCloud
    • Objets/résultats cherchant dans les 2 noeuds supérieurs : AFC, Classification, Dimensions de partition, Progression, Histogramme de spécificités, TextBalance, WordCloud

[SJ, en cours, TXM 0.8.0, 2019-10-30] hiérarchies qui pourrait être créées :

Note : à mon sens il faudrait dissocier le CorpusEngine du SearchEngine mais c'est une autre histoire (Voire SearchEngine deviendrait QueryEngine).

• SearchEngine, noeud alternatif [encoding, language, …]
  • Commandes : Import, ???
    • Objets/résultats : Corpus, ???

• Pagination, noeud alternatif [n_lines_per_page, current_page_index]
  • Commandes + Objets/résultats : Tous les résultats de type tableau : Concordance, Index, Lexique, Spécificités, Cooccurrence, ???

Exemples d'autres hiérarchies ou scopes à implémenter :

• SearchEngine (scope globale : encoding par défaut, langue par défaut, etc.)
  • CQPSearchEngine (scope moteur : peut redéfinir l'encoding, etc.)
    • CQPCorpus (scope résultat : peut redéfinir l'encoding, etc.)
  • TigerSearchEngine (scope moteur : peut redéfinir l'encoding, etc.)
    • TigerCorpus (scope résultat : peut redéfinir l'encoding, etc.)

• Pagination (scope globale : nombre de lignes par page par défaut, etc.)
  • Index (scope commande : peut redéfinir le nombre de lignes par page par défaut, etc.)
    • Index (scope résultat : peut redéfinir le nombre de lignes par page par défaut, etc.)
  • Concordance (scope commande : peut redéfinir le nombre de lignes par page par défaut, etc.)
    • Concordance (scope résultat : peut redéfinir le nombre de lignes par page par défaut, etc.)
  • etc.

• supprimer toutes les popups de paramétrage (ex : Progression, spécificités…)
• chaque éditeur de commande doit avoir une zone de paramètres retractable (il peut y avoir beaucoup de paramètres)
  • Peut être une une ligne avec un bouton “>” “v” (ou “cacher”, “afficher”)
  • Peut être un bouton “>” “v” qui s'affiche en haut à gauche (ou droite) par dessus le résultat. Il faudrait pouvoir déplacer le bouton au cas où il generai la lecture du résultat)
  • Peut être une barre avec menus (comme le menu principal)

Il y a 2 groupe de préférences :

• Avancées : réglage du fonctionnement (des moteurs?) de TXM (Stat, CQP, Rendu, TAL…)
• Utilisateurs : réglages du fonctionnement des calculs de TXM (Concordance, Index…)

Zones de paramètres :

• Requête : sur une ligne
  • Label “Requête”
  • Bouton assistant
  • Champ de saisie (+historique)
  • Bouton “+” (pour rajouter une requête)
  • Bouton “Calculer/Chercher”
  • Bouton “Paramètres”
• Propriétés : dans un agencement de type tableau
  • L1: Références, Ctx G., Pivot, Ctx D.
  • L2: Aff. + 1 combo par colonne. Une combo de sélection unique/multiple ordonné/non-ordonné contient des propriétés de mot et/sans propriétés de structure
  • L3: Tri + IDEM que L2
• Tris : sur une ligne
  • Label “#1” + combo des noms de colonnes triables + bouton de sens de tri. autant de “#X+combo” que de colonnes affichées
• Taille : sur une ou plusieurs ligne
  • de -( ) à -( ) et de ( ) à ( ) pour les concordances il faut retirer “à -( ) et de ( ) ”.
  • radio : “occurence” “structure”
    • “structure” active : un combo contenant les propriétés de structures et le bouton radio “include la structure du pivot”
  • boutons checks : “contexte gauche actif” “contexte droit actif”
• Progression : sur une ligne
  • Cumulatif
  • Densité, active
    • largeur de bande
• Progression : sur une ligne
  • champ “structure” qui active
  • champ “propriété” qui active
    • champ “Exp reg. des valeurs”
    • bouton check “Répéter”
• Style de ligne : sur une ligne
  • couleur
  • niveaux de gris
  • noir & blanc (traits différents)
• Seuils quantitatifs : sur une ligne
  • champ Fmin
  • champ Fmax
  • champ Vmax (Lexique, Index, AFC)
  • champ Cmin
  • champ Indice

Déplacer les paramètres des boites de dialogues des commandes dans les éditeurs

Unifier l'UI de paramétrage

1. les éditeurs (TXMEditor) contiennent :
   • une bande avec des paramètres “toujours visibles” et des toolbars
     • avec une toolbar par défaut : “toptoolbar”
     • suivi d'éventuelles autres toolbar (le bouton trier de la commande Information de partition) séparée par des séparateur
   • des zones de paramètres
   • une zone résultat
   • une bande de toolbar avec
     • une toolbar basse “bottomtoolbar”
   • des zones de paramètres
2. la toolbar par défaut “toptoolbar” contient
   • des widgets partagés entre les TXMResults :
     • un bouton de calcul+recalcul du résultat
     • un bouton d'export du calcul
     • un bouton de zone “Computing parameters” → “Parameters”
   • pour les charts : un bouton de zone “Rendering parameters” → “Rendering”
3. la toolbar par defaut “bottomtoolbar” contient :
   1. une zone de navigation (sans bouton d'ouverture/fermeture)
4. les zones de paramètres des éditeurs sont
   1. décomposée en sections thématique (calcul, rendu)
   2. refermable

Les boutons de zones vides ne doivent pas être afficher

Les boutons de zone ont un style différent et sont séparés des autres boutons : décorator de flèche bas

• Un éditeur de résultat peut rajouter des toolbars
• Reprendre et s'inspirer des UI de paramétrage du portail (Concordances, Index, Cooccurrences)

Organisation d'un éditeur résultat de TXM se décompose en :

• Toolbar de paramétrage découpée en plusieurs sections
• Panneau d'affichage du résultat
• Toolbar de navigation dans le résultat

→ c'est l'arrangement actuel de la Concordance

Les sections de paramétrage et navigation doivent pouvoir être visible ou pas et extensibles. Par exemple pour la concordance :

• section requête (toujours visible)
• section options d'affichage
• section options de tri
• section annotation
• …

Si un éditeur a besoin de montrer des compléments du résultat, éviter les éditeur multipart (qui ne peuvent pas profiter de l'API des fenêtre d'Eclipse) et préférer :

• d'avoir plusieurs onglets dans l'éditeur (voir éditeur de configuration de l'import) = vue différente sur le résultat sans avoir besoin de faire des aller-retours
• d'ouvrir un nouvel éditeur lié = vue qui permet de faire des aller retour entre les 2 éditeurs

Si chaque commande est capable de dire quels sont les paramètres dont elle a besoin alors :

• Une vue pourrait utiliser l'éditeur (d'une commande) courant pour afficher les paramètres de la commande
• Tout ou partie des paramètres pourraient être affichés dans cette vue
• La vue peut être :
  • Déplacée dans la fenêtre principale
  • détachée de la fenêtre principale
• Problème : les paramètres

• pour les concordances: reproduire le formulaire du portail dans la RCP
• les menu contextuels pourraient faire un focus sur le champ de paramétrage concerné (ex: le menu contextuel de la concordance : si on sélectionner “propriété d'affichage” avec la souris dans la colonne pivot, focus sur la propriété d'affichage du pivot)
• le focus de partie des spécificités pourrait être remplacer par un mécanisme semblable à la boite de dialogue du lien Index vers Table lexicale mais pour le lien Partition vers Table lexicale.
• Table lexicale:
  • retirer le bouton “Fusion/Suppression lignes”
  • renommer “Fusion/suppresion colonnes” par “colonnes…”
  • dans la boite de dialogue “Fusion/Suppresion colonnes” : remplacer les boutons radio par 2 boutons (push)
• Progression
  • Utiliser la même UI que partition avancé pour ajouté des requêtes