Liste de liens :
Liste de liens :
Les commandes de TXM partagent une façon d'organiser leurs paramètres et de les présenter dans les éditeurs.
Une commande :
Les valeurs par défaut des paramètres d'une commande sont construites à partir :
Exemple de parcours de résolution de la valeur par défaut du paramètre “police des labels” d'une AFC :
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.
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 :
Les Scopes de préférences Eclipse:
classe “TXMPreferences” de TXM (à completer&préciser):
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 :
Lors du calcul/compute d'un résultat :
À l'ouverture d'un résultat :
[SJ, en cours, TXM 0.8.0, 2019-10-30] hiérarchie actuelle des paramètres héritées :
[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).
Exemples d'autres hiérarchies ou scopes à implémenter :
Il y a 2 groupe de préférences :
Zones de paramètres :
Déplacer les paramètres des boites de dialogues des commandes dans les éditeurs
Unifier l'UI de paramétrage
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
Organisation d'un éditeur résultat de TXM se décompose en :
→ 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 :
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 :
Si chaque commande est capable de dire quels sont les paramètres dont elle a besoin alors :