Différences

Cette page vous donne les différences entre la révision choisie et la version actuelle de la page.

public:retours_de_bugs_logiciel:txm_0.8.0 [2018/12/18 13:56]
sebastien.jacquot@univ-fcomte.fr
public:retours_de_bugs_logiciel:txm_0.8.0 [2019/04/16 17:54] (version actuelle)
alexei.lavrentev@ens-lyon.fr
Ligne 1: Ligne 1:
-====== Retours TXM 0.8.0 ======+====== Retours TXM 0.8.0 ======
Cette page contient les discussions et les retours de bugs de TXM 0.8.0. Cette page contient les discussions et les retours de bugs de TXM 0.8.0.
Ligne 5: Ligne 5:
Vous pouvez ajouter vos discussions et retours à la fin de cette page. Vous pouvez ajouter vos discussions et retours à la fin de cette page.
-Pour information, la liste des bugs non résolus, c'est-à-dire que cette version ne cherche pas à résoudre, se trouve ici : [[http://forge.cbp.ens-lyon.fr/redmine/projects/txm/issues?query_id=34|kown-bugs (bugs connus)]]+Pour information, la liste des bugs non résolus, c'est-à-dire que cette version ne cherche pas à résoudre, se trouve ici : [[http://forge.cbp.ens-lyon.fr/redmine/projects/txm/issues?query_id=34|known-bugs (bugs connus)]]
-====== ALPHA 1 ======+====== ALPHA ======
-===== Démarrage =====+Retours de la phase ALPHA (terminée) :
-SLH (07/06/2018) : +  * [[public:retours_de_bugs_logiciel:txm_0.8.0alpha]]
-  - pas possible de conserver dans le lanceur à la fois l'icone de TXM 0.8.0 et TXM 0.7.9 (le lanceur - icone - d'un TXM 0.8.0 correspond à celui - celle du TXM 0.7.9)+
-GL (11/12/2018) : +====== BETA ======
-Les corpus de 0.7.9 ne sont apparemment pas compatibles avec le format 0.8 : +
-Installing sample corpus... +
-    VOEUX.txm binary corpus is not a TXM 0.8.0 corpus (no .settings nor .project file) +
-    graal.txm binary corpus is not a TXM 0.8.0 corpus (no .settings nor .project file) +
-    Done. +
-    2 corpus loaded. +
-    TXM is ready.+
-===== Menus & Toolbars=====+Retours de la phase BETA : merci de répartir vos retours dans les sections thématiques ci-dessous ou dans de nouvelles sections.
-SLH (07/06/2018) :+===== Installation =====
-  - <del>'Fichier > Charger > un corpus (.txm)...' -> 'Fichier > Charger > un corpus binaire (.txm)...' [pour être homogène avec 'Fichier > Charger > un corpus répertoire de corpus binaires...']</del> +AL 2019-02-11 (Ubuntu 16.04) 
-  - <del>'Fichier > Importer' : mettre un séparateur devant 'CQP' [qui se distingue du reste]</del> +  * TXM ne demande pas où il faut créer le répertoire utilisateur TXM et récupère tous les corpus de l'ancienne version. Ça peut être lourd, surtout en période de test
-  - <del>'Fichier > Importer > CNR+CSV' -> 'Fichier > Importer > Cordial+CSV' [pour être homogène avec Alceste, Hyperbase, etc.]</del> +    * **MD corrigé** : TXM demande maintenant quels corpus restaurer au premier lancement [[http://forge.cbp.ens-lyon.fr/redmine/issues/2509|ticket #2509]] 
-  - <del>'Fichier > Nouveau fichier' -> 'Fichier > Nouveau...'</del> +  * Installation du TreeTagger : le modèle fro.par est installé sans que l'utilisateur le demande. 
-  - <del>'Fichier > Changer la langue' -> 'Affichage > Changer la langue'</del> +    * **MD corrigé**
-  - toolbar des perspectives : +
-    - <del>nommer Corpus ou C le bouton de la perspective Corpus [comme le bouton de la pers. R se nomme R]</del> +
-    - <del>mettre un flyover "ouvrir la perspective Corpus' sur le bouton de la perspective Corpus</del> +
-      * MD: ok j'ai renommer la perspective en "ouvrir la perspective Corpus", ce qui affiche le bon tooltip +
-    - <del>mettre un flyover "ouvrir la perspective R' sur le bouton de la perspective R</del> +
-      * MD: ok j'ai renommer la perspective en "ouvrir la perspective R", ce qui affiche le bon tooltip +
-  - toolbar : +
-    - <del>flyover 'Créé [sic] un nouveau fichier' -> 'Éditer un nouveau fichier'</del> +
-    - <del>flyover 'Ouvrir un fichier ()' -> 'Ouvrir un fichier' </del>  +
-      * <del>SJ: je pense que les parenthèses sont dûes à un mnemonic vide mais je ne trouve pas la définition</del> +
-      * <del>MD: il restait un paramètre de commande vide qui provoquait l'affichage des parenthèses "()"</del>+
-VL (02-07) 
-Dans le menu, serait-il possible d'harmoniser les langues utilisées ?  
-    - <del>"Internal view" pourrait devenir "Vue interne" ; </del> [SJ: fait] 
-    - "Sub-corpus" pourrait devenir "Créer un sous-corpus" ou "Sous-corpus";  
-    - "Create partition" pourrait devenir "Créer une partition" ou "Partition"; 
-    - "Rename" pourrait devenir "Renommer"  
-  * [SLH, 12/07] : nous sommes en train de finaliser le nouveau workflow de finalisation/correction/traduction des chaines de l'interface utilisateur 
-===== Commande Concordance =====+BP 2019-03-05 (Ubuntu 16.04, TXM 0.8.0.1826, 0.8.0.201902271548) 
 +  * TXM 0.8.0b3 ne se désinstalle pas avec la logithèque. On peut faire une désinstallation avec "sudo apt-get remove txm-0.8.0b3". Chaque ancienne version de TXM semble cependant laisser un répertoire sous usr/lib, je ne sais pas si c'est normal. 
 +    * **MD reporté pour 0.8.1** c'est normal, dans l'état les setups alpha, beta et stable n'ont pas la même nom de version et ne se connaissent pas entre eux: [[http://forge.cbp.ens-lyon.fr/redmine/issues/2529|#2529]] 
 +    * **BP** : mais ici je voulais aborder la question de la désinstallation propre, demandée par l'utilisateur, et non celle de la désinstallation gérée automatiquement par l'installation d'une nouvelle version (qui est importante aussi bien sûr). 
 +      * **MD reporté pour 0.8.1 ** [[http://forge.cbp.ens-lyon.fr/redmine/issues/2550|#2550]] 
 +  * Quelques messages d'erreur quelques minutes (~5 mn ?) après le 1er lancement et la récupération des corpus (ici minimisée, limitée à l'installation des corpus GRAAL et VOEUX). <code> 
 +!ENTRY org.eclipse.core.resources 2 2 2019-03-05 11:55:42.691 
 +!MESSAGE Save operation warnings. 
 +!SUBENTRY 1 org.eclipse.core.resources 2 234 2019-03-05 11:55:42.691 
 +!MESSAGE The project description file (.project) for 'GRAAL' was missing.  This file contains important information about the project.  A new project description file has been created, but some information about the project may have been lost. 
 +!SUBENTRY 1 org.eclipse.core.resources 2 234 2019-03-05 11:55:42.692 
 +!MESSAGE The project description file (.project) for 'VOEUX' was missing.  This file contains important information about the project.  A new project description file has been created, but some information about the project may have been lost. 
 +</code> 
 +    * **MD corrigé**
-BP : <del>Quand je redémarre TXM, les deux concordances que je voulais supprimer sont bien parties, mais aussi un corpus avec ! Finalement un peu plus tard (après autres redémarrages ?) le corpus disparu semble revenu. Ai-je mal vu ??</del> [SJ: fixé] 
-SJ : bug de pack des colonnes difficilement identifiable (semblant lié à la taille du pivot ?), ex. : 1) faire une cooc sur VOEUX avec la requête "fa.*" avec structure sur "p" 2) envoyer "souhaite" vers les concordances => la colonne du pivot est énormément large+FB 2019-03-06
-SJ : par ailleurs la colonne ref plante parfois, premières lignes vides+  * pour la langue française du moins, la segmentation ne se fait plus au niveau de l'apostrophe (par exemple, "c'est" est un seul mot) problème Treetagger ? Problème segmentation ? 
 +    * **SLH corrigé** : c'est lié au problème déjà mentionné "La langue d'annotation sélectionnée par défaut est “FR”" alors qu'elle devrait être "fr"\\ -> positionner la langue d'annotation à "fr" dans le formulaire d'import
-==== Annotation ====+SLH 2019-03-24 (Ubuntu 18.04) 
 +  * fenêtre logithèque : 
 +    * logo de TXM ? 
 +    * license : propriétaire ? 
 +    * taille : 0 octet ? 
 +    * **MD je donne ma langue au chat** [[http://forge.cbp.ens-lyon.fr/redmine/issues/2551|#2551]]
-  * <del>BP : la sauvegarde n'a pas fonctionné</del> +===== Démarrage =====
-    * MD : j'ai fait des corrections + vérifications +
-      * SJ: toujours buggé pour l'annotation par Mots, la sauvegarde ne fonctionne pas + les messages de l'UI ne sont pas en UTF-8, donc probs d'accents, etc.+
-===== Commande Cooccurrence =====+MD 2019-03-19 
 +  * Windows : Les chemins de lancement de TXM ne sont pas bons. 
 +    * **MD corrigé dans le setup b4**
-SJ :+SLH 2019-03-24 (Ubuntu 18.04) 
 +  * TXM-0.8.0 n’apparaît pas dans la recherche du Dash -> obligé de le lancer depuis un terminal 
 +  * l'icone de TXM 0.8.0 dans le lanceur est la même que celle de TXM 0.7.9 -> on ne peut pas lancer TXM 0.7.9 et TXM 0.8.0 en même temps depuis le lanceur 
 +  * **MD reporté** [[http://forge.cbp.ens-lyon.fr/redmine/issues/2552|#2552]]
-  - auto compute ou pas des résultats ? généralisé sur tous les widgets ou seulement quelques-uns ? +BP 2019-04-02, BP 2019-04-05 (Ubuntu 16.04, TXM 0.8.0, 0.8.0.1928, 0.8.0.201903221605) 
-    * [SLH, 12/07] : je pense que la remarque de BP est qu'il y a des paramètres (widgets ?) qui changent beaucoup la nature de certains calculs, que du coup un certain nombre de paramètres complémentaires doivent être réglés avant de recalculer, et donc que l'auto compute ne doit pas être déclenché pour ces paramètres. Mais ça ne me semble pas remettre en cause l'auto-compute. +  * Le lancement de TXM me paraît très long : ~8 minutes. Il y a une quinzaine de corpus mais une majorité de petits corpus, de moins de qq centaines de milliers de mots. J'ai supprimé le corpus BFM016DD qui était plus gros (4 millions de mots, avec une dizaine de partitions ou sous-corpus), il me semble que le seul corpus conséquent qui reste est AFVOIXOFFSUJ, 3 millions de mots **mais** 12 000 (petits) textes. 
-      * il faudrait préciser commande par commande, paramètre par paramètre si auto-compute ou pas ? +    * **MD corrigé**
-  - tri multiple par défaut ou pas ? +
-    * MD: L'interface n'est pas prête pour ça, mais on peut peut-être le faire juste quand on tri sur l'indice : +
-      * Indice puis Cofréquence puis Fréquence ? +
-  - <del>a faire : tri par défaut : Indice décroissant</del> +
-    - MD: **OK** c'est déjà le cas+
-===== Commande Lexique =====+==== Récupération des corpus ====
-SLH (07/06/2018) : +MD - 2019-03-08
-  - commande Lexique : <del>- on change la propriété -> le nom de la colonne change mais le contenu et la fréquence restent 'word'</del> [SJ: fixé temporairement, voir [[http://forge.cbp.ens-lyon.fr/redmine/issues/2398]]] +
-    * SJ : <del>on ne peut pas réouvrir un lexique par double-clic [en attente de voir si on refont ou pas les 2 classes Lexicon/Index]</del> [SJ: fixé par MD mais la refonte du lexique n'est pas complètement terminée, voir ticket]+
-===== Commande Internal View =====+La non-récupération des corpus du précédent TXM 0.8.0 créé des corpus cassés 
 +  * **MD corrigé**
-VL (02/07) :  +JCD - 2019-03-02
-  - <del>En cas de présence d'un guillemet anglais, lorsqu'un clic sur « envoyer vers concordance/index/progression » est opéré, rien ne se passe (fenêtre de requête vide).</del> [MD: **OK** corrigé] +
-  - Si on tente de forcer la requête %%[word="\""]%%, message d'erreur +
-SJ: +
-  - <del>la réouverture après rechargement ne fonctionne pas</del> [SJ: fixé]+
-===== Commande Spécificités ===== +Les corpus récupérés ne sont pas affichés 
- +  * **MD corrigé** la vue corpus n'était pas bien rafraîchie et le travail de récupération n'était pas bloquant
-BP: <del>SPÉCIFICITÉS sur table lexicale, marges = index : +
-il me semble qu'avant quand on triait sur le score de spécif on commençait par un tri décroissant pour voir d'abord les mots les plus spécifiques (S+), là on commence par voir les S-, ce serait mieux si on pouvait commencer par les S+ comme avant ? </del> [SJ: fixé] +
- +
-BP : <del>titre de la spécificité calculée sur un sous-corpus "TLNONAME:word"</del> [MD : **OK** j'ai laissé juste la propriété utilisée] +
- +
-SJ: +
-  - <del>Graphique de spécifs: la réouverture après rechargement ne fonctionne pas</del> [SJ: fixé] +
- +
-===== Commande table lexicale ===== +
- +
-VL (02-07) +
- - <del>proposition de  changer le terme « parameters » en paramètre</del> [SJ: fixé]  +
- +
-===== Commande propriétés ===== +
- +
-SLH (05/06/2018) : +
- +
-  - <del>la toolbar est cool</del> +
-  - <del>la possibilité de régler en temps réel les paramètres montre qu'une Vmax à 100 par défaut est probablement mieux</del> +
-  - dans la zone des paramètres, il n'est pas nécessaire de suffixer les noms de paramètres par ' :', le changement de couleur et de widget suffit à montrer la différence entre le label et le champ de saisie +
-    * MD: j'ai retiré les ":" des principaux paramètres  +
-  - le bouton Apply pour chaque property [du corpus] c'est sûrement too much -> un seul bouton Apply ou Save bien situé +
-  - il faut en plus à côté un bouton Cancel, équivalent au re-clic sur 'edit properties' qui ferme la zone +
-  - peut-être aussi modifier le bouton 'edit properties' avec une flèche vers le bas quand c'est pour ouvrir, puis avec une flèche vers le haut quand c'est pour fermer la zone (comme dans les boutons équivalents du portail) +
-    - SJ: je propose d'utiliser le même bouton que pour les annotations +
-  - <del>le changement du nom du corpus c'est très cool -> faudra mettre le ticket à ~100%</del> +
-  - dans la toolbar, il faudrait donner un aspect [bouton] à Compute et à 'edit properties', comme c'est le cas pour Parameters +
-  - 'edit properties' -> 'corpus properties' ou 'properties' +
-  - dans le titre du HTML résultat de la commande : 'Détails du corpus CQP VOEUX' -> 'Propriétés générales[internes ?] du corpus CQP VOEUX' +
- +
-===== Commande progression ===== +
- +
- +
-BP: +
- +
-- <del>Suppression d'une requête OK (mais le graphique ne se met pas à jour automatiquement, il faut par exemple faire "entrée" dans le champ d'une autre requête)</del> [SJ: fixé] +
- +
-SJ:  +
- +
-- <del>ajouter un test pour ne pas ajouter 2 fois la même requête dans le QueryWidget (cela fait planter le graphique). Le test est fait dans la ligne de requête principale mais pas dans le QueryWidget [SJ: fixé. Mais un message d'erreur "The query already exists." dans la console n'est pas suffisant à mon sens. Mettre une dialog box ?]</del> +
-  * <del>[SLH, 12/07] :</del> +
-    * <del>oui, un boite de dialogue modale me semble appropriée dans ce cas, le message d'erreur pourrait être plutôt : "That query is already represented by a curve in the graphic. Please use another Query." [SJ: fixé. Messages actuels : EN: "The query {x} is already represented by a curve in the graphic. Please use another query.", FR: "La requête {x} est déjà présente dans le graphique."]</del> +
-      * <del>[SLH, 31/07] mise à jour du message français, calque de la version anglaise :</del> +
-        * <del>FR: "La requête {x} est déjà représentée dans le graphique par une courbe. Veuillez utiliser une autre requête."</del> [SJ: fixé] +
- +
-SLH (08/06/2018) : +
- +
-  * actuellement dans la progression, le contenu du label fixe (en haut à gauche dans ma figure) +
-n'est pas le même que celui du label dynamique (en bas à droite dans ma figure) :\\ {{:public:retours_de_bugs_logiciel:progression-hobbes.png?400|}} +
- +
-<code> +
-02decive, 8.13, 189+
-139216 / 451747+==== Changement de langue de l'interface ====
-117 / 561+AL 2019-02-13 
 +  * La commande Affichage/Changer la langue ne fonctionne pas (l'interface reste toujours en français). Pour forcer le lancement en anglais MD propose le patch suivant dans le fichier ~/TXM-0.8.0/.txm/TXM.ini, ajouter avant la ligne '-vmargs'<code> 
 +-nl 
 +en
</code> </code>
 +    * **MD corrigé**
 +  * Lorsque l'OS est en russe, TXM se lance en russe. L'affichage du cyrillique dans le menu et dans les noms de certains onglets est incorrect (UTF-8 lu comme iso-latin ?)
 +    * **MD en cours** au moins pour la Beta les messages russes sont retirés. Ils pourront être réintégrés lors d'une mise à jour ou nouvelle version de TXM.
 +      * **AL** <html><span style="color:red">2019-03-01.</span></html> Le russe est disparu du menu de sélection de langue, mais l'interface reste en cyrillique cassé après installation sur un windows russe (confirmé sur deux machines). Ça donne une très mauvaise impression aux utilisateurs...
 +        * **MD reporté** [[http://forge.cbp.ens-lyon.fr/redmine/issues/2553|#2553]]
 +  * Lorsque l'interface est en anglais, certaines commandes restent en français :
 +    * menu Corpus : toutes les commandes sauf "re-import corpus"
 +    * menu Tools : toutes les commandes
 +    * menu View : Réinitialiser affichage
 +    * idem pour les commandes dans le menu contextuel
 +      * **MD bugs connus** reporté à plus tard [[http://forge.cbp.ens-lyon.fr/redmine/issues/2554]]
-versus+SLH 2019-03-24 (Ubuntu 18.04) 
 +  * interface en EN : 
 +    * le démarrage EN annonce la date et la version, "Starting TXM 0.8.0.1928 (23 March 2019, 16h27)…", alors que le démarrage FR ne donne pas la date : "Démarrage de TXM 0.8.0.1928…" 
 +      * **MD reporté** [[http://forge.cbp.ens-lyon.fr/redmine/issues/2555]] 
 +    * l'onglet de la vue Fichier garde son nom FR : "Fichier" -> "File" 
 +    * la majorité des entrées du menu principal restent en FR 
 +      * dont "Fichier > Vérifier les packages R" 
 +      * "File > New?", le '?' est en trop, à moins que ce soit des '...' qui ont été remplacés à tort par un '?' 
 +      * "File > Open in Browser?", le '?' est en trop ou un bug 
 +      * "File > Changer le répertoire de travail", doit être traduit, et n'aurait pas du être remplacé par une Préférence ? 
 +      * la majorité des entrées du menu contextuel restent en FR 
 +      * **MD reporté** voir ci-dessus 
 +  * interface en FR : 
 +    * le menu contextuel de la console est en EN 
 +      * **MD corrigé** 
 +  * menu contextuel "Export > Corpus in binary format?", le '?' est en trop ou un bug 
 +    * **MD corrigé**
-<code>[lemma="king"] (119 / 961)</code>+==== Conservation des requêtes ====
-Or il y a des éléments du label fixe qui seraient intéressants dans le label dynamique (surtout la réf car elle aide à savoir où on est tout en bougeant le point).+  * FB - 2019-03-06 
 +    * Ok pour cocher pour les garder tous par défaut mais je ne vois pas à quoi correspond "à la demande (mode de fonctionnement par défaut)" 
 +    * **SLH** s'il s'agit de la persistence des résultats, la terminologie actuelle de TXM est la suivante : 
 +      * en général les commandes prennent en entrée une requête CQL pour produire un résultat 
 +      * la persistence porte sur les résultats [obtenus] plutôt que sur les requêtes [en entrée] (parce qu'il n'y a pas que les requêtes qui sont à l'origine de résultats mais également plein d'autres paramètres par ailleurs - comme des seuils, etc.) 
 +      * par défaut un résultat n'est pas sauvegardé pour les sessions suivantes (non persisté) 
 +        * donc il faut demander explicitement de le sauvegarder/persister si on veut qu'il perdure entre les sessions de TXM (-> "à la demande (mode de fonctionnement par défaut)") 
 +      * l'enregistrement entre sessions de TXM et la gestion de requêtes CQL utilisées pour un corpus font l'objet d'un composant qui n'est pas encore publié 
 +    * **MD documenté** [[http://forge.cbp.ens-lyon.fr/redmine/issues/2543]]
-Ce serait pas mieux de mettre les mêmes infos dans les deux ? (voir en déplacer : eg la requête dans le fixe)+==== Affichage de la console ====
-Une autre idée : documenter un peu les infos+  * FR - 2019-03-11 
-Par exemple :+    * Au démarrage de TXM, la date affichée par la console n'est pas à jour.  
 +      * **MD corrigé** La data a été retirée. TXM affichait la date d'installation de TXM.
-<code>ref: 02decive, 8.13, 189+===== Onglet corpus =====
-position: 139216 / 451747+AL 2019-02-11 
 +  * Le fonctionnement de la barre de statut a évolué depuis 0.7.9, l'affichage varie selon les objets sélectionnés. Voici l'état actuel et quelques suggestions d'harmonisation : 
 +    * pour un corpus, ça affiche le nom du corpus (c'était le nombre de mots avant). L'info est moins utile que le nombre de mots, mais OK. 
 +      * BP 2019-04-02 (Ubuntu 16.04, TXM 0.8.0, 0.8.0.1928, 0.8.0.201903221605) : je viens de le constater aussi ; je m'aperçois que je me servais bien de ce nombre de mots mais bon ce n'est pas prioritaire. 
 +        * **MD corrigé** tous les résultats n'ont pas encore leur message [[http://forge.cbp.ens-lyon.fr/redmine/issues/2530|#2530]] 
 +    * pour une description, toujours le nom de l'objet. Suggestion : ajouter "Description :" 
 +    * pour un sous-corpus : le nom du sous-corpus. Suggestion : ajouter le nom du corpus parent 
 +    * pour une partition : nom de la partition + nombre de parties 
 +    * pour une concordance : nom du corpus ou sous corpus + requête, suggestion : ajouter "Concordance :" 
 +    * pour un lexique : nom du corpus + propriété, suggestion : ajouter "Lexique :" 
 +    * pour un index : "Index:" + requête, suggestion : ajouter le nom du corpus 
 +    * pour une progression : nom du corpus: + requête en doubles crochets. Suggestion : ajouter "Progression:", enlever les crochets en trop... 
 +      * **MD en cours** résolution au moins après la Beta
-order: 117 / 561</code>+FR 2019-03-11 
 +   * On ne peut plus accéder aux fonctions de calcul en cliquant dessus le nom des corpus : la seule possibilité consiste à utiliser la barre d'outils. 
 +     * **MD reporté** [[http://forge.cbp.ens-lyon.fr/redmine/issues/2556]]
-On pourrait aussi justifier le label en profitant d'une police à casse fixe :+BP 2019-04-15 (Ubuntu 16.04, TXM 0.8.0.2009, 0.8.0.201904121205) 
 +  * Quand je sélectionne un cube de partition, en bas de la fenêtre s'affiche par exemple "10 built part(s)" (en interface FR). Ce que je veux signaler c'est que le nombre est instable : en début de session j'ai eu 9, puis après qq clics 8, puis je crois après un calcul de PROPRIÉTÉS 9, puis après un autre calcul (INDEX) 10, puis à chaque nouvel INDEX ou PROPRIÉTÉS le nombre semble s'incrémenter (11, 12...) 
 +    * **MD corrigé**
-<code>ref:  02decive, 8.13, 189+===== Messages =====
-position: 139216 / 451747+SLH 2019-03-24 (Ubuntu 18.04) 
 +  * la commande "Fichier > Charger corpus binaire..." n'affiche pas de message quand elle a terminé. Elle affiche seulement indéfiniment : Chargement du corpus binaire au format 0.7.9 HOBBES8.txm... 
 +    * **SJ: fixé par MD** 
 +    * <code>Chargement du corpus binaire au format 0.7.9 GRAAL.txm... 
 +GRAAL corpus chargé(s).</code>
-order:       117 /    561</code> +===== Chaînes =====
-  * <del>idée : créer un raccourcis RETURN équivalent au double-clic sur un point (ouverture de concordance). En effet, souvent on se déplace sur une courbe avec les flèches et le RETURN serait plus rapide pour ouvrir une concordance à partir du point où on se trouve. En fait c'est peut-être l'occasion de designer un premier scénario basé entièrement sur des raccourcis pour naviguer entre ces outils (en plus des interactions avec la souris et souris+clavier) ;</del> [SJ: fait, voir: [[http://forge.cbp.ens-lyon.fr/redmine/issues/2470]]] +
-  * le retour au texte double ne fonctionne pas bien. Un scénario habituel est d'analyser deux courbes en même temps -> du coup on ouvre deux concordances en même temps et on a envie d'avoir deux retours au texte en même temps. Or les éditeurs d'édition se mélangent entre les deux concordances à partir d'un moment +
-    * SJ (14.11.2018): après tests je ne crois pas avoir de problème, est-il possible d'avoir des précisions ? testé: 2 courbes sur "faire" et "lui" => double clic sur un point de "faire", déplacement dans les courbes avec les flèches => ouvre une 2e concordance quand on arrive sur la courbe "lui" => déplacement avec les flèches => met bien à jour l'une ou l'autre des concordances (NOTE: les comportements semblent un peu différents entre Win et Linux, notamment toujours sur ces questions de focus de composant UI) +
-  * autre idée : pouvoir ouvrir une édition à la place d'une concordance (par exemple avec un Alt-clic en complément du Double-clic) -> pour naviguer dans l'édition à partir de la courbe plutôt que dans la concordance, c'est-à-dire privilégier d'emblée une lecture au contexte large.\\ variante : maintenir l'édition et pouvoir y naviguer quand on ferme la concordance qui a ouvert l'édition.+
 +SLH 2019-04-16 (TXM 0.8.0.2018, Ubuntu 16.04)
 +  * commande interne de rechargement des corpus binaires par répertoires :
 +    * chaines non externalisées (?) :
 +      * <code>Restoring corpora</code>
 +      * <code>A corpus with the same CQP MainCorpus identifier DEMOCRATLYON3 already exists. Aborting loading of /home/sheiden/TXM/corpora/DEMOCRATLYON3_TEMP.</code>
 +      * <code>A corpus named GRAAL already exists, loading of /home/sheiden/TXM/corpora/GRAAL canceled.</code>
 +      * <code>Warning no corpus element defined in the /home/sheiden/TXM-0.8.0/corpora/P1S8S/import.xml file.</code>
 +    * message difficile à interpréter pour l'utilisateur, utile ?
 +      * <code>Informations de l'espace de travail (selfElement null)</code>
 +===== Commandes =====
-===== Recette 0 =====+JCD - 2019-03-02
-AL (2018-06-06)+Faut il vraiment que le menu « propriétés «  présent la position vide. Pourquoi ne pas mettre un epropriété par défaut, par exemple « word » qui est probablement la plus utilisée ?  
 +  * **MD corrigé**
-  * <del>Installation sous Ubuntu 16.04 : OK</del> +===== Commande Propriétés (ex Description/Informations) =====
-    * <del>(La recette ne dit pas s'il faut fermer TXM 0.7.9 avant l'installation, il était fermé)</del> +
-  * <del>2 répertoires sont créés : TXM_0.8.0 et TXM-0.8.0, mais c'est peut-être normal</del> [MD: nope c'est corrigé, on utilise "-" **OK**] +
-  * <del>Messages de la console :</del><code> +
-Warning: NLS unused message: common_structuralUnit in: org.txm.core.messages.messages +
-Warning: NLS missing message: common_strucutralUnit in: org.txm.core.messages.messages +
-Démarrage de TXM 0.8.0 (2018-06-05 13h38)... +
-Création de l'espace de travail utilisateur de TXM. +
-Chargement des sous-corpus et des partitions...Terminé. +
-Moteur statistique lancé.Connecté. +
-Prêt. +
-Chargement des sous-corpus et des partitions...Terminé. +
-Prêt. +
-</code> +
-    * MD: faute de frappe **OK** +
-  * <del>Tentative de récupération des corpus 0.7.9 :</del> +
-    * <del>Commande Fichier > Charger > un répertoire de corpus binaires : OK</del> +
-  * Bugs constatés :  +
-    * <del>menu Aide, dernière entrée intitulée "%command.label.141"</del> [MD : la chaîne était absente et l'entrée de menu mal placée **OK**] +
-    * corpus GRAAL et VOEUX : message "corpus not ready", disparaît au 2e lancement +
-  * Tentative d'import XTZ : <code>Sauvegarde des paramètres d'importation... +
-Error: org/txm/importer/xtz/xtzLoader.groovy not found. +
-Extraction of ressource failed from /usr/lib/TXM-0.8.0/plugins/org.txm.groovy.core_1.0.0.201806051338.jar with path org/txm/importer/xtz/xtzLoader.groovy +
-Error: can't find import script in plugin resources: /home/.../TXM_0.8.0/scripts/import/xtzLoader.groovy </code>+
-===== Recette 1 =====+AL 2019-02-11
-AL (2018-06-06)+  * La date de création de tous les corpus est me 31/12/2018, l'heure semble être celle du système au moment de la création ou chargement du corpus 
 +    * **MD corrigé**, pour les corpus TXM 0.7.9 chargés dans TXM 0.8.0, la date de création sera effectivement la date du chargement du corpus 
 +  * Pour un nouveau corpus la date de dernière modif est bonne, mais elle re-passe au 31/12/2018 après redémarrage de TXM 
 +    * **MD corrigé**
-  * Import (menu accessible, mais ne fonctionne pas) +BP 2019-03-19 (Ubuntu 16.04, TXM 0.8.0 beta 4, 0.8.0.1913, 0.8.0.201903181603)
-  * <del>Chargement : +
-    * <del>corpus binaire : OK</del> +
-    * <del>répertoire de corpus : OK</del> +
-  * Vue corpus +
-    * Renommage de corpus : OK, mais le titre de l'onglet "Description" ne change pas (même si on on appelle la commande sur un corpus après le renommage), après redémarrage de TXM le corpus reprend son nom d'origine, la modif de la description persiste +
-    * <del>Modif Vmax OK, mais il semble y avoir une limite non explicitée sur le nombre de propriétés (20 ?) [SJ: devenu obsolète ? à checker]</del> +
-      * <del>SJ: actuellement le max semble être 100, est-ce normal ?</del> [MD : **OK** c'était la valeur par défaut du widget, on peut monter à 1000 si 100 est la valeur par défaut] +
-  * <del>Progression</del> +
-    * <del>Ajout de requêtes : OK, modification des réglages : OK, sauf</del> +
-      * <del>ajout de structures : le graphique n'affiche plus rien, il faut modifier un autre réglage pour que tout se remette en place</del> [SJ: fixé]+
- +  * J'ai installé TXM 0.8.0 beta 4 sans récupérer aucun corpus. J'ai refait l'import de mon corpus ELYSEE depuis ses sources. Quand je demande ses propriétés (mais je pense avoir fait d'autres commandes et redémarré depuis l'import), j'obtiens une erreur sur les dates malgré la correction faite par Matthieu (cf. retours d'Alexei ci-dessus) : <code> 
-===== Autour de la persistance des résultats d'une session à l'autre =====  +Date de création : 31 décembre 2018, 14h46 
- +Dernière modification : 31 décembre 2018, 14h48.
- +
-VL (02-07) +
-Concernant mon utilisation de TXM, j'ai tendance à procéder par "sauts de puce" et à accumuler de très nombreuses vues (concordanciers, index, etc.) durant une session (même courte). J'ai l'habitude de "sauvegarder" (en les exportant) uniquement les vues qui méritent un retour lors d'une session ultérieure. D'une session à l'autre, une persistance de toutes les vues représenterait pour moi un coût important :  +
-  * en clics pour tout fermer et avoir un confort de travail dans ma nouvelle session ;  +
-  * et en attention, puisqu'il s'agit de ne pas supprimer la vue qui m'intéresserait même si elle est noyée dans une liste de 40 vues.  +
-Je n'ai pas pu faire le test avec des vues renommées (en raison du bug lié au renommage), mais je crois qu'il ne faudrait pas négliger le coût cognitif qui serait celui de l'utilisateur pour retrouver les éléments pertinents perdus dans une très (très) longue liste.  +
- +
-Est-ce qu'une sauvegarde par type de résultats serait éventuellement techniquement possible ? +
-Exemple : la sauvegarde d'une matrice lexicale apporte un grand confort et une sécurité intéressante pour l'utilisateur, qui a certainement passé du temps à la modifier (fusion des lignes, suppression, etc.)+
-A l'opposé, convoquer un concordancier nécessite un très faible investissement de l'utilisateur (sauf en cas de requête très - très- sophistiquée): on pourrait donc discuter de l'apport de la sauvegarde automatique de cette vue d'une session à l'autre... +
-  * [SLH 12/07] : +
-    * On peut inverser le scénario en effet : punaiser explicitement les résultats que l'on souhaite conserver, et ne pas recharger (oublier) les résultats non punaisés au prochain lancement +
-      * éventuellement proposer une nouvelle commande "Nettoyer les résultats [non punaisés]" appliquée à la hiérarchie d'un objet désigné dans la vue Corpus ou à toute la vue, pour clarifier la vue Corpus de tout ce qui n'a pas été punaisé +
-      * éventuellement proposer une nouvelle commande "Exporter les résultats" appliquée à la hiérarchie d'un objet désigné dans la vue Corpus, pour créer autant de fichiers d'export que d'objets punaisés +
-        * question subsidiaire : peut on imaginer d'exporter (ou sauvegarder) un résultat, ou une hiérarchie de résultats, au sens où on pourrait le reconstruire/recalculer dans TXM comme s'il avait été punaisé ? Est-ce que ça permettrait d'échanger des résultats de sessions de travail entre utilisateurs de TXM sur un même corpus, sous-corpus, partition, etc. +
-        * SJ: c'est techniquement possible mais on a actuellement une limitation qui est la récupération automatique du résultat parent, pour les corpus l'ID est/sera le CQP ID donc c'est bon mais pour les sous-corpus et partition c'est plus compliqué car le nom peut ne pas être le même sur 2 machines différentes +
-          * propositions: +
-            *  ajouter une commande "greffer" un résultat qui tente d'importer un result sur le noeud où elle est appelée (et si elle "foire", elle "foire" avec les messages qui vont bien) +
-            * utiliser un sha/md5/etc pour vérifier que le parent est compatible/unique (d'une manière générale ça peut aussi être intéressant pour comparer/authentifier différentes versions d'un corpus mais sur quoi faire la signature ?) +
-        * MD: la parenté des résultats est assuré par le noeud de préférence mais pas par le CQPID. La nouvelle commande cloner le résultat et ses descendants, correspond à la commande clone le résultat + greffer les descendants au clone +
-    * Oui on peut créer une liste de commandes à punaiser par défaut (nouvelle préférence ?) : sous-corpus, partition, table lexicale +
-      * SJ: je suis pour. Note dev: Etat actuel avant les vacances : "Store this result" via le context menu permet de définir un result en persistable. Préférence globale "Auto save results" qui passe tous les results en persistable dès qu'ils sont créés. Tous les résultats sont persistés, peu importe si l'option est cochée ou non ou si le user a forcé un store result ou non. Les results sont donc tous persistés et les results non persistés (et fichiers) sont effacés au shutdown de la toolbox. Choix actuel avec Matt pour récupération en cas de crash. +
-        * nécessite discussions pour les noms de commandes et préférences et UI pin/coche/etc +
-        * nécessite discussions et devs pour la récup en cas de crash +
- +
-====== ALPHA 2 ====== +
- +
-Cette section a été créée par SLH le 09/10/2018 pour la version TXM 0.8.0.1180 (de status alpha 2). +
- +
-Attention : les installeurs de TXM 0.8.0 alpha 2 sont régulièrement mis à jour en fonction des retours. Pour connaître la version précise du TXM téléchargé et évalué, il faut regarder le numéro indiqué dans la console au démarrage.\\ Par exemple :\\ <code>Démarrage de TXM 0.8.0.1180...Terminé. +
-Prêt.</code> +
- +
-Si le numéro mineur du TXM que vous évaluez est différent de 1180, merci de le préciser au début de chaque retour. +
- +
-===== Installation et installation multiple (recette 0), Démarrage et vrac ===== +
- +
-  * SJ (18/10/2018, Win64) : +
-    * <del>au premier démarrage, l'installation des corpus d'exemple devrait se faire avec une progress bar modale car là TXM semble prêt alors qu'il ne l'est pas. L'interface est accessible alors que des processus cruciaux sont encore en cours d'exécution</del> [SJ: ticket [[https://forge.cbp.ens-lyon.fr/redmine/issues/2429#change-7046]]] +
-    * <del>manque un fichier :</del> +
-      * <del>!ENTRY org.eclipse.jface 4 0 2018-10-18 16:34:24.062 !MESSAGE /icons/functions/save.png !STACK 0 java.io.FileNotFoundException: /icons/functions/save.png</del> [MD: **OK** les icones de org.txm.annoattion.kr.rcp n'étaient pas exportés] +
-    * bug de Theme toujours présent : +
-      * <code>!ENTRY org.eclipse.e4.ui.css.swt.theme 4 0 2018-10-18 16:31:19.787 +
-       !MESSAGE  +
-      !STACK 0 +
-      java.net.MalformedURLException +
-   at java.net.URL.<init>(URL.java:627) +
- at java.net.URL.<init>(URL.java:490) +
- at java.net.URL.<init>(URL.java:439) +
- at org.eclipse.e4.ui.css.core.impl.engine.AbstractCSSEngine.parseStyleSheet(AbstractCSSEngine.java:211) +
-... +
-        Caused by: java.lang.NullPointerException +
- at java.net.URL.<init>(URL.java:532) +
- ... 29 more</code> +
-   * BP (19/10/2018, TXM 0.8.0.1196) : <del>Dans l'application d'installation d'ubuntu, le numéro de version indiqué est 0.7.9. Et après l'installation, je n'ai plus mon TXM 0.7.9 (l'icône a disparu du lanceur et quand je fais une recherche sur "txm" dans l'outil de recherche de programmes d'ubuntu, je n'ai que quatre 0.8.0 (alpha2 ou pas, Debug ou pas). Dans mon HOME j'ai trois répertoires : TXM, TXM-0.8.0, TXM-0.8.0a2.</del> [MD **OK** j'ai écrasé TXM 0.7.9 lors de l'installation, c'est corrigé depuis] +
-   * BP (19/10/2018, TXM 0.8.0.1196) : il y a un certain nombre de messages d'erreur au premier lancement, dont concernant R<code> +
-Warning: image not found in 'org.txm.rcp' -> 'icons/logo/TXM logo.png' +
-Warning: image not found in 'org.txm.rcp' -> 'icons/logo/TXM logo 64x64.png' +
-Démarrage de TXM 0.8.0.1196... +
-Création de l'espace de travail utilisateur de TXM. +
-Terminé. +
-..........Rserve not started with /usr/lib/TXM-0.8.0a2/plugins/org.txm.statsengine.r.core.linux_1.0.0.1188/res/linux64/bin/R. Trying with commons R installation paths (will works if Rserve, textometry and FactoMineR are installed). +
-....................Impossible de démarrer RServe. +
-org.txm.statsengine.r.core.exceptions.RWorkspaceException: ** Le chemin du programme du serveur statistique a été renseigné mais sa recherche a échoué dans : /usr/lib/TXM-0.8.0a2/plugins/org.txm.statsengine.r.core.linux_1.0.0.1188/res/linux64/bin/R. +
- at org.txm.statsengine.r.core.RWorkspace.initRserve(RWorkspace.java:352) +
- at org.txm.statsengine.r.core.RWorkspace.startExec(RWorkspace.java:483) +
- at org.txm.statsengine.r.core.RStatsEngine.start(RStatsEngine.java:63) +
- at org.txm.core.engines.EnginesManager.startEngines(EnginesManager.java:98) +
- at org.txm.Toolbox.startEnginesManagers(Toolbox.java:531) +
- at org.txm.Toolbox.initialize(Toolbox.java:260) +
- at org.txm.rcp.ApplicationWorkbenchAdvisor$8$1.run(ApplicationWorkbenchAdvisor.java:1095) +
- at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:119) +
-Prêt. +
-Installing sample corpus... +
-VOEUX.txm binary corpus is not a TXM 0.8.0 corpus (no .settings nor .project file) +
-graal.txm binary corpus is not a TXM 0.8.0 corpus (no .settings nor .project file) +
-Terminé. +
-2 corpus loaded. +
-TXM est prêt.+
</code> </code>
-   * BP (19/10/2018, TXM 0.8.0.1196) : au second lancement et après redémarrage complet de la machine, les messages d'erreurs sont réduits mas il y a toujours le pb concernant R <code> +    * **MD corrigé** 
-Démarrage de TXM 0.8.0.1196... +   * Par ailleurs la "Description" qui est donnée ne reprend pas celle que j'avais entrée dans le formulaire d'import, voici celle qui s'affiche : <code> 
-Terminé. +Build the Alceste import module
-..........Rserve not started with /usr/lib/TXM-0.8.0a2/plugins/org.txm.statsengine.r.core.linux_1.0.0.1188/res/linux64/bin/R. Trying with commons R installation paths (will works if Rserve, textometry and FactoMineR are installed). +
-....................Impossible de démarrer RServe. +
-org.txm.statsengine.r.core.exceptions.RWorkspaceException: ** Le chemin du programme du serveur statistique a été renseigné mais sa recherche a échoué dans : /usr/lib/TXM-0.8.0a2/plugins/org.txm.statsengine.r.core.linux_1.0.0.1188/res/linux64/bin/R. +
- at org.txm.statsengine.r.core.RWorkspace.initRserve(RWorkspace.java:352) +
- at org.txm.statsengine.r.core.RWorkspace.startExec(RWorkspace.java:483) +
- at org.txm.statsengine.r.core.RStatsEngine.start(RStatsEngine.java:63) +
- at org.txm.core.engines.EnginesManager.startEngines(EnginesManager.java:98) +
- at org.txm.Toolbox.startEnginesManagers(Toolbox.java:531) +
- at org.txm.Toolbox.initialize(Toolbox.java:260) +
- at org.txm.rcp.ApplicationWorkbenchAdvisor$8$1.run(ApplicationWorkbenchAdvisor.java:1095) +
- at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:119) +
-Prêt.+
</code> </code>
-    * en tout cas il y a bien un fichier R au bout du chemin indiqué sur mon DD : /usr/lib/TXM-0.8.0a2/plugins/org.txm.statsengine.r.core.linux_1.0.0.1188/res/linux64/bin/R +    * **MD corrigé**
-    * et c'est aussi le chemin réglé dans les préférences : /usr/lib/TXM-0.8.0a2/plugins/org.txm.statsengine.r.core.linux_1.0.0.1188/res/linux64/bin/R +
- +
-  * BP (19/10/2018, TXM 0.8.0.1196) : <del>on ne peut pas charger de binaires réalisés avec la 0.7.9, enfin on a un message d'erreur (ci-après), mais le corpus semble quand même disponible (information, édition, concordance, etc.).<code> +
-AFNOTICES-V2-2018-10-02.txm binary corpus is not a TXM 0.8.0 corpus (no .settings nor .project file) +
-</code></del> [MD **OK** j'ai ajouté un message qui confirme le format lu au chargement du corpus] +
- +
-===== vue Corpus ===== +
- +
-  * SLH (09/10/2018) : de façon générale, dans le menu contextuel des objets de la vue Corpus +
-    * <del>mettre Conserver devant Renommer...</del> +
-      * <del>MD corrigé en attente de test</del> [SJ: OK] +
-    * mettre un séparateur devant Préférences +
-      * MD corrigé en attente de test +
-        * SJ: OK testé mais je pense qu'il faudrait virer cette entrée de menu, d'autant plus qu'elle ne pointe même pas vers les prefs de la commande +
-  * AL (09/10/2018) +
-    * il n'y a plus de commande "supprimer". Comment faire pour supprimer un corpus, un sous-corpus ou une partition ? Pour les résultats on peut décocher "Conserver" et relancer TXM, mais ce n'est pas très pratique +
-      * MD corrigé en attente de test +
-        * SJ: OK testé. En revanche pour le menu global, l'entrée apparaît dans "Corpus" => bug ? +
-          * MD: non +
-           * SJ: c'est vraiment bizarre que pour supprimer un résultat on doive faire "Corpus\Supprimer" ? +
-    * <del>le bouton "conserver" est-il utile sur les corpus, sous-corpus et partitions ?</del> +
-      * <del>MD corrigé en attente de test</del> [SJ: OK] +
-    * <del>le renommage d'un corpus fonctionne et persiste - OK</del> +
-  * BP (19/10/2018, TXM 0.8.0.1196) :  +
-    * <del>j'ai renommé un corpus, j'ai renommé et sauvegardé certains résultats, tout cela semble bien fonctionner.</del> +
-    * <del>je pense que le comportement "pas sauvé par défaut" est bien, et la notation étoilée pour signaler les résultats caduques.</del> +
- +
-===== Vue Interne ===== +
- +
-  * BP (19/10/2018, TXM 0.8.0.1196) : <del>les boutons pour naviguer dans les pages ne semblent pas actifs.</del> +
-    * SJ: <del>je confirme, bug sous Win aussi</del> [SJ: fixé] +
-  * BP <del>(19/10/2018, TXM 0.8.0.1196) : le nom de la commande est en anglais (idem pour : Sous-corpus, Partition, les commandes sous TreeTagger</del> [MD : **OK**+
- +
-===== Commande Propriétés de corpus et sous-corpus =====+
-  * SLH (09/10/2018) : +SJ 2019-03-15
-    * <del>Supprimer le bouton Compute ?</del> [SJ: finalement il faut le laisser pour le mode non électrique, à cause du spinner VMAX] +
-    * <del>l'appel successif de Propriétés sur un même corpus multiplie les résultats (icones enfant, dans la vue Corpus) : est-ce vraiment utile ? (comportement différent d'avant 0.8.0)</del> +
-      * <del>MD corrigé en attente de test*</del> [SJ: OK]+
-  * BP (19/10/2018, TXM 0.8.0.1196) //(feature ?)// : <del>Il me semble que la commande s'appelait avant "Description". Il faudra réfléchir à unifier la terminologie et à l'accorder avec l'icône (I -> informations ?). Dans l'affichage des résultats, le titre est "détails" d'un corpus et "Dimensions" d'une partition.</del> +  * Le champ V Max est mal branché au ComputeListener (la touche Entrée ne fonctionne pas + en mode électrique le clic sur les flèches du Spinner recalcule automatiquement le résultat mais ne devrait pas
-    * SLH : <del>l'idée est de généraliser cette commande à tous les objets de la vue Corpus tout en s'alignant sur la terminologie usuelle des explorateurs de répertoires et fichiers des systèmes d'exploitation. La terminologie devrait être "Propriétés [du corpus]|[de la partition]|..." pour tous les objets.</del>+    * **SJ corrigé**
===== Commande Édition ===== ===== Commande Édition =====
-  * SLH (09/10/2018) : +  * AL 2019-04-16 (TXM 0.8.0.201904161055
-    * <del>supprimer le bouton Compute (peut il avoir un rôle ?)&lt;del&gt; +    * Lorsqu'on arrive à la dernière page du dernier texte d'un corpus et qu'on clique sur &quot;page suivante&quot;, TXM affiche la 1ère page du dernier texte. Idem, si on clique sur &quot;page précédente&quot; à la 1ère page du 1er texte, TXM affiche la dernière page de ce 1er texte.
-      * <del>MD: pour l'instant il est grisé et la toolbar est visible&lt;/del&gt; [SJ: j'ai supprimé le bouton mais la zone de toolbar reste visible (Win64), ticket : [[https://forge.cbp.ens-lyon.fr/redmine/issues/2478]] ]+
-===== Commande Lexique =====+===== Commande Navigateur/Browser (ex Vue interne) =====
-  * SLH (09/10/2018) : +AL (2019-02-11)
-    * mettre le bouton Compute à droite du bouton Paramètres -> mettre le bouton Compute systématiquement à l'extrémité droite de toutes les fenêtres résultats ?+
-  * BP (19/10/2018, TXM 0.8.0.1196) : +  * La navigation par page ne fonctionne pas (c'est toujours la 1ère page qui s'affiche) 
-    * <del>Si je veux saisir une Fmin (ou Fmax ou Vmax ou Résultats par page), je ne peux pas saisir deux chiffres d'affilée (la saisie du 2e chiffre part dans un autre champ en bas à droite de la fenêtre). Cela semble lié au mode électrique (le résultat est recalculé dès l'entrée du premier chiffre).</del> [SJ: fixé]] +    * **MD corrigé** 
-    * quand je double-clique sur un résultat précédent, son onglet ne revient pas sur le dessus dans l'affichage à droite. +  * Un astérisque est toujours affiché à côté de l'objet dans le volet corpus (avant et après la conservation), il disparaît si on ferme l'onglet
-      * SJ: non reproductible sous Windows +    * **MD corrigé** l'astérisque était lié au bug précédent 
-  * MD: &lt;del&gt;j'ai une ouverture très lente de la concordance qui peut donner l'impression que la concordance ne se re-ouvre pas</del> [MD: **OK** le ralentissement était du à l'affichage du détail de la concordance dans la barre de status (message trop long)]+  * L'icone &quot;roue dentée&quot; ne correspond plus au nouveau nom de la fonction 
 +    * **MD corrigé** nouvelle icone {{http://www.famfamfam.com/lab/icons/silk/icons/application_form_magnify.png}} (loupe sur un tableau)
-===== Commande Concordance =====+FB (2019-02-18)
-  * BP (19/10/2018, TXM 0.8.0.1196) : +  * La vue requête provoque une erreur pour une version ubuntu 18.04 (mais la conservation des requêtes est ok via le changement dans les préférences
-    * <del>Quand on lance (crée) une nouvelle concordance (un nouvel onglet), on a un message d'erreur, qui pourrait être lié au mode électrique.<code> +    * **MD vue retirée** la vue n'est pas encore prête et doit être repensée pour mieux s'intégrer avec le reste des outils de TXM
-oncordance.canCompute(): Query is not set or empty. +
-TXMResult.compute(): Concordance: can not compute, missing or wrong parameters or error with parent computing, computing aborted. +
-TXMEditor.compute(): ConcordanceEditor: computing failed. +
-</code></del> +
-      * <del>SJ: il s'agit seulement du log, on devrait passer ce message en warning</del> +
-    * <del>Si on a 8 lignes de concordance, l'affichage de la pagination indique 1-9 / 8 ; si on a 139 lignes, la page 1 affiche 1-100 / 139, et la page 2 101-140 / 139.</del> +
-      * <del>MD **OK** on a du le corriger entre temps<del/> +
-    * Si j'édite les annotations des mots et que je veuille modifier à la fois le lemme et la pos pour une même sélection de lignes, je n'arrive pas à appliquer les deux modifications en même temps, et je n'arrive pas non plus à garder la sélection de lignes pour les opérer successivement. +
-    * Dans le menu contextuel, plutôt que "Options d'affichage des contextes" (ce qui était déjà le cas avant) cela me paraîtrait plus clair d'avoir "Taille des contextes".+
-===== Commande Cooccurrence ===== 
-  * <del>SJ (18/10/2018) :</del> +===== Commande Sous-corpus ===== 
-    * <del>la commande ne fonctionne pas. Par ailleurs il y a 2 appels à compute() successifs.</del> [SJ: fixé dans l'alpha3] +===== Commande Partition =====
- +
-===== Commande Spécificités ===== +
- +
-  * SJ (25/10/2018) : +
-    * <del>la commande ne fonctionne pas depuis un sous-corpus, Specificities.getPartShortNames() essaie de récupérer les noms depuis une partition parente</del> [MD **OK** j'ai simplifié le code interne qui était trop compliqué à gérer]+
 +===== Commande Lexique =====
===== Commande Index ===== ===== Commande Index =====
-  * <del>SLH (09/10/2018) :</del> +BP 2019-03-22 (Ubuntu 16.04, TXM 0.8.0 beta 4, 0.8.0.1913, 0.8.0.201903181603) 
-    * <del>il y a un sélecteur de moteur (menu avec 'CQP' par défaut) devant la saisie de la requête, mais concordances, cooccurrences, etc. n'en ont pas -> le retirer temporairement de l'index ou le mettre à toutes les commandes</del> +  * Quand je modifie une requête et que je relance le calcul de l'index, l'affichage du résultat n'est pas repositionné pour démarrer à la première ligne. 
-      * <del>MD corrigé en attente de test</del> [SJ: OK] +    * ** MD corrigé** 
-  * <del>AL (09/10/2018) :</del> +  * Je suis en train d'utiliser l'index, et je décide de changer de stratégie de recherche en utilisant la macro SetMatchingStrategy. Après avoir fait tourner la macro, le bouton flèche verte qui permet de relancer le calcul (sur la même requête pour voir l'effet du changement de stratégie) n'est plus actif. Je ne réussis à le réactiver qu'en changeant de requête
-    * <del>L'appel de la commande devrait placer le curseur dans le champ de saisie de requête, comme c'était le cas dans les versions précédentes</del> +    * **MD corrigé** on a retiré la désactivation du bouton 
-      * <del>MD corrigé en attente de test</del> [SJ: OK] +  * L'historique des requêtes inclut une sélection de lignes copiées d'un résultat d'index ! J'ai fait plusieurs opérations de la sorte -sélection puis copie dans un index- mais une seule d'entre elles a intégré le menu. 
-  * BP (19/10/2018, TXM 0.8.0.1196) : +    * **MD pas réussi à reproduire**
-    * <del>comme dans le Lexique, on ne peut pas saisir deux chiffres dans les seuils, le calcul se relance dès la saisie du premier et le second par dans un autre champ (requête).</del> [SJ: fixé]+
-===== Commande Sous-corpus =====+BP 2019-04-02 (Ubuntu 16.04, TXM 0.8.0, 0.8.0.1928, 0.8.0.201903221605) 
 +  * Ce retour concerne plus généralement le champ Requête CQP (j'observe le même bug en concordance par exemple) : Si je lance la requête <code>"[A-Z].+"</code> alors celle-ci s'exécute correctement, mais dans le champ requête la requête perd ses guillemets ; elle les perd aussi dans l'historique des requêtes. Du coup, lorsqu'on veut relancer la requête, cela génère une erreur CQP. 
 +    * **MD corrigé** [[http://forge.cbp.ens-lyon.fr/redmine/issues/2531|#2531]]
-  * BP (19/10/2018, TXM 0.8.0.1196) : <del>simple OK, avancée OK.</del>+===== Commande Index de partition =====
 +BP 2019-03-22 (Ubuntu 16.04, TXM 0.8.0 beta 4, 0.8.0.1913, 0.8.0.201903181603)
 +  * Je reviens sur un index déjà calculé (avec des descendants : table lexicale, spécifs, graphe de spécif) et je décide de changer la requête en en sélectionnant une autre dans l'historique. Mais le bouton flèche verte pour lancer le calcul est désactivé, et je n'arrive pas à le réactiver (en changeant de requête, en entrant une nouvelle requête, etc.)
 +    * **MD corrigé** voir plus haut
-===== Commande Partition =====+===== Commande Concordance =====
-  * SLH (09/10/2018) : +SLH 2019-02-11
-    * <del>l'appel de Spécificités ou de Table lexicale ne fonctionne pas, avec l'erreur :\\ <code>LexicalTable.canCompute(): can not compute with no unit property. +
-TXMResult.compute(): LexicalTable: can not compute, missing or wrong parameters or error with parent computing, computing aborted. +
-TXMResult.compute(): Specificities: failed to compute parent result. +
-TXMEditor.compute(): SpecificitiesEditor: computing failed.</code>\\ -> dans ce cas un objet TL sans label est créé dans la vue Corpus, est-ce nécessaire ?</del> +
-      * <del>SJ: malentendu ici, on a oublié de préciser quelque chose dans le mail, on génère maintenant des résultats vides pour les LT, Specifs, etc. l'utilisateur doit ensuite choisir la propriété avant que le calcul ne puisse être lancé</del> +
-    * <del>manque l'appel de la CAH</del> +
-      * <del>MD corrigé en attente de test</del> [SJ: OK] +
-  * AL (09/10/2018) : +
-    * <del>L'appel direct des commandes LT et Specif provoque l'erreur dans la console, mais si je double-clique sur l'objet et sélectionne une propriété, ça marche</del> +
-      * <del>MD **corrigé en attente de test**</del> +
-      * <del>SJ: malentendu ici, on a oublié de préciser quelque chose dans le mail, on génère maintenant des résultats vides pour les LT, Specifs, etc. l'utilisateur doit ensuite choisir la propriété avant que le calcul ne puisse être lancé</del> +
-    * <del>La commande Specificités est accessible à partir du menu contextuel, mais il n'y a pas d'icone correspondante dans la barre de menu</del> +
-      * <del>MD corrigé en attente de test</del> [SJ: OK]+
-  * BP (19/10/2018, TXM 0.8.0.1196) : +  * <del>quand je lance une concordance, le champ CQL initial contient la chaine "". Est il possible d'avoir un champ vide à la place ? (comme avant, et comme pour la commande Index)</del> 
-    * simple OK +    * **SJ: corrigé**
-    * assistée : instable ? +
-      * la fenêtre de construction disparaît quand je crée la 4e partie qui aurait sans doute du s'afficher sur une 2e ligne. Le cube de partition apparaît dans la vue Corpus : la partition semble disponible mais seulement avec les 2 premières parties. +
-      * j'essaye de reproduire le bug, je recommence la création de la même partition en lui donnant un nom différent. Tout se passe bien jusqu'à la création de la 5e et dernière partie, je crois que c'est au moment où j'affecte les valeurs dans la partie que la fenêtre explose. La partition est créée mais ne compte que 4 parties.+
-===== Commande Index de partition =====+BP 2019-03-05 (Ubuntu 16.04, TXM 0.8.0.1826, 0.8.0.201902271548) 
 +  * Quand je double-clique sur une ligne pour revenir au contexte large dans l'Edition, l'occurrence concernée n'est pas mise en évidence par le surligné rose. En revanche à partir du 2e clic (quand je sélectionne une autre ligne qui appelle une **autre** page de l'édition), le surlignage se fait. 
 +    * **MD corrigé** 
 +  * Je parcours toutes les lignes de la première page de concordance. Puis je passe à la page suivante, et je suis surprise parce que je suis positionnée à la fin de la page (comme quand j'ai quitté la page 1), je m'attendrais à voir affiché le début de la 2e page pour continuer la lecture des lignes 98, 99, 100 aux lignes 101, 102, 103 etc. 
 +    * **MD corrigé** le bouton page suivante remonte l'ascenseur en début de page
-  * SLH (09/10/2018) : +FR 2019-03-15
-    * <del>manque l'appel de Propriétés</del> +
-      * <del>SJ: nouvelle commande ? que doit-elle faire ?</del> +
-        * <del>SLH : la même chose que pour Partition, dans un premier temps, en affichant également les marges des index.</del> [SJ: ticket : [[http://forge.cbp.ens-lyon.fr/redmine/issues/2479]]] +
-    * <del>manque l'appel de Spécificités</del> +
-      * <del>MD corrigé en attente de test</del> [SJ: OK] +
-    * <del>manque l'appel de l'AFC</del> +
-      * <del>MD corrigé en attente de test</del> [SJ: OK] +
-    * <del>manque l'appel de la CAH</del> +
-      * <del>MD corrigé en attente de test</del> [SJ: OK]+
-===== Commande Table lexicale =====+  * Le scroll synchronisé des 2 tableaux de concordances ne fonctionne pas lorsque l'on scroll en utilisant l'ascenseur 
 +    * **MD corrigé**
-  * SLH (09/10/2018) : +BP 2019-03-19 
-    * <del>manque l'appel de Propriétés -> même traitement que pour Partition</del> [SJ: ticket [[http://forge.cbp.ens-lyon.fr/redmine/issues/2485]]] +  * on ne peut pas supprimer une ligne de concordance lors que l'on annote 
-    * <del>manque l'appel de CAH</del> +    * **MD corrigé**
-      * <del>MD corrigé en attente de test</del> [SJ: OK]+
-===== Commande AFC ===== +BP 2019-03-21 (Ubuntu 16.04, TXM 0.8.0 beta 4, 0.8.0.1913, 0.8.0.201903181603) 
- +  * J'ai fait un retour au texte en double-cliquant sur une ligne de la concordance. Si ensuite j'édite la requête CQL et je relance le calcul avec la flèche verte à droite du champ requête de la concordance, alors rien ne bouge dans le résultat de la concordance (le calcul pour la nouvelle requête ne se fait pas) alors que l'édition associée se repositionne au début du texte (pour le texte en cours). 
-  * SLH (09/10/2018) : +    * **MD en cours** [[http://forge.cbp.ens-lyon.fr/redmine/issues/2557]] 
-    * la version du package FactoMineR provoque une erreur :\\ -> <code>org.txm.statsengine.r.core.exceptions.RException: ** Erreur R : "Error : Ceci est R 3.2.3, le package ‘FactoMineR’ nécessite >= 3.3.0 +    * **MD en cours** [[http://forge.cbp.ens-lyon.fr/redmine/issues/2558]] 
-+  * Lorsque je fais évoluer la requête de la concordance, il est arrivé que l'édition de retour au texte associée conserve (certains ?) surlignages d'une recherche antérieure (mais pas de toutes les recherches antérieures). Je ne suis pas très précise car je n'ai pas réussi à cerner plus précisément le cas de figure dans lequel cela se produit. 
-lors de l'évaluation de : library(FactoMineR) +    * **MD lié au bug précédent** 
- at org.txm.statsengine.r.core.RWorkspace.safeEval(RWorkspace.java:1424) +  * Lorsqu'on exporte une sélection de lignes par copier/coller, on n'a plus l'information de la référence (1ère colonne - d'où viennent l'occurrence et ses contextes), c'est assez embêtant quand même... (difficile de s'en passer donc on la remet à la main) 
- at org.txm.statsengine.r.core.RWorkspace.voidEval(RWorkspace.java:1559) +    *  **SJ: reporté**, voir ticket [[http://forge.cbp.ens-lyon.fr/redmine/issues/2522]]
- at org.txm.ca.core.statsengine.r.functions.FactoMineRCA.loadLibrary(FactoMineRCA.java:455) +
- at org.txm.ca.core.statsengine.r.functions.FactoMineRCA.<init>(FactoMineRCA.java:108) +
- at org.txm.ca.core.functions.CA._compute(CA.java:178) +
- at org.txm.core.results.TXMResult.compute(TXMResult.java:1906) +
- at org.txm.core.results.TXMResult.compute(TXMResult.java:1960) +
- at org.txm.core.results.TXMResult.compute(TXMResult.java:1960) +
- at org.txm.core.results.TXMResult.compute(TXMResult.java:1960) +
- at org.txm.core.results.TXMResult.compute(TXMResult.java:1960) +
- at org.txm.core.results.TXMResult.compute(TXMResult.java:1866) +
- at org.txm.core.results.TXMResult.compute(TXMResult.java:1825) +
- ...</code> +
-      * SJ (18/10/2018) : tout fonctionne sous Win chez moi, Matt tu peux investiguer sous Linux ? +
-    * impossible de choisir les axes +
-      * SJ (18/10/2018) : tout fonctionne sous Win chez moi, Matt tu peux investiguer sous Linux ? +
-    * le déplacement et l'extension de la sélection de lignes d'infos lignes ne fonctionne plus +
-      * SJ (18/10/2018) : tout fonctionne sous Win chez moi, Matt tu peux investiguer sous Linux ? +
-    * pourquoi la police par défaut des labels de points dans les plans sont dans la police Abyssinica SIL ? +
-      * SJ: à creuser, pouvez vous me donner le nom d'une police UTF-8 embeded dans Linux ? +
-    * le raccourcis Ctrl-S sur l'icone résultat AFC ne fonctionne pas +
-      * SJ: non reproductible ici +
-        * SJ: en fait il s'agit peut-être d'un bug général => si la vue corpus n'a pas le focus, le raccourci CTRL+S ne fonctionne sur aucun des résultats +
-    * <del>à la ré-ouverture, le label textuel associé à l'icone a disparu</del> +
-      * <del>SJ: précision: à la réouverture de session => bug de lazy name</del> [SJ: fixé, il y avait également le même bug dans la Table Lexicale]+
 +SLH 2019-03-24 (Ubuntu 18.04) :
 +  * quand on avance d'une page de concordance, la colonne Référence reprend sa largeur d'origine, même si on l'a redimensionnée, alors que l'offset de la scrollbar horizontale de la colonne Référence est elle bien conservé -> il ne faut pas redimensionner d'office la colonne des Références à chaque changement de page
 +    * **MD corrigé** sauf à l'ouverture des concordances conservées
 +===== Commande Cooccurrence =====
 +BP 2019-04-05 (Ubuntu 16.04, TXM 0.8.0, 0.8.0.1928, 0.8.0.201903221605)
 +  * Lors du retour au texte, la requête cherche toujours les 2 mots dans les deux ordres possibles, même si on n'a cherché les cooccurrents que d'un côté.
 +    * **MD reporté** [[http://forge.cbp.ens-lyon.fr/redmine/issues/2559]]
===== Commande Progression ===== ===== Commande Progression =====
-  * SLH (09/10/2018) : +AL 2019-02-11
-    * <del>ajouter Return sur point sélectionné comme raccourci clavier de double-clic sur un point (ouverture de concordance)</del> [SJ: fait] +
-  * AL (09/10/2018) : +
-    * <del>L'appel direct de la commande sur un corpus provoque l'erreur "can not compute with no query"</del> +
-      * <del>SJ: il s'agit seulement du log, on devrait passer ce message en warning</del> +
-    * Les labels de progression sont en crochets (doubles crochets si la requête CQL en a déjà. +
-      * SJ: tu parles bien de crochets ou bien de guillemets ? on a un léger souci en ce moment sur la restauration des requêtes, les requêtes basiques du type : faire - sont sauvées de manière interne en : "faire" et à la restauration on a donc les guillemets +
-  * SJ (18/10/2018) : +
-    * <del>passer en mode densité ne fonctionne pas</del> [SJ: fait, force le passage en mode R]+
-===== Commande Import =====+  * Les crochets sont dupliqués dans la requête qui s'affiche dans le volet corpus <nowiki>[[frpos="VER:impf"]]</nowiki> 
 +    * SJ: les premiers crochets sont utilisés en tant que marqueur de liste, ce n'est pas à proprement parlé un bug mais peut-être qu'il faudrait changer le pattern pour l'affichage ? 2 exemples avec 3 requêtes ci-dessous 
 +      * <nowiki>[[frpos="PRO:PER"], [frpos="PRO:REL"], [frpos="VER:pper"]]</nowiki> 
 +      * <nowiki>[[word="est"], [word="pour"], [word="une"]]</nowiki> 
 +        * SH: proposition : {...} (usage peu fréquent dans les textes)\\ -> 
 +          * <nowiki>{[frpos="PRO:PER"], [frpos="PRO:REL"], [frpos="VER:pper"]}</nowiki> 
 +          * <nowiki>{[word="est"], [word="pour"], [word="une"]}</nowiki> 
 +          * question : dans le cas soulevé par Alexis, c'est à dire un singleton, est il nécessaire de formuler sous la forme d'une liste (d'un seul élément) ? 
 +        * MD : et '''%%[frpos="PRO:PER"], [frpos="PRO:REL"], [frpos="VER:pper"]%%''' ? 
 +          * **SJ: fix de MD au 22-02-2019**: les crochets ont été supprimés et une virgule sépare les requêtes, 2 exemples avec 3 requêtes : 
 +            * <nowiki>[frpos="PRO:PER"], [frpos="PRO:REL"], [frpos="VER:pper"]</nowiki> 
 +            * <nowiki>"est", "pour", "une"</nowiki>
-==== Module XTZ ==== 
-  * AL (09/10/2018) : 
-    * Testé le corpus IMMONDEPRK : Tout se passe bien jusqu'à l'étape de production de l'édition 
-<code> 
--- Building 'default' edition of  1 texts... 
- .Error: could not create /home/alavrent/TXM-0.8.0a2/corpora/IMMONDEPRK/txm/IMMONDEPRK/ImMondePrK.xml 'default' edition: javax.xml.stream.XMLStreamException: No element was found to write: java.lang.ArrayIndexOutOfBoundsException: -1 
--- Building 'default' XSL edition with step 'html'... +SJ 2019-02-12
-Exception in thread "Thread-112" groovy.lang.MissingPropertyException: No such property: ApplyXsl2 for class: org.txm.scripts.importer.xtz.XTZPager +
- at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:67) +
- at org.codehaus.groovy.runtime.callsite.GetEffectivePogoPropertySite.getProperty(GetEffectivePogoPropertySite.java:87) +
- at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGroovyObjectGetProperty(AbstractCallSite.java:310) +
- at org.txm.scripts.importer.xtz.XTZPager.doPostEditionXSLStep(XTZPager.groovy:312) +
- at org.txm.scripts.importer.xtz.XTZPager.process(XTZPager.groovy:54) +
- at org.txm.importer.xtz.ImportModule$2.run(ImportModule.java:164) +
---- Copying subdirectories [xsl, css, dtd] +
-.. +
-Terminé. +
-</code> +
-    * MD **corrigé en attente de test** +
-  * L'import écrase sans avertissement un ancien corpus avec le même d'origine s'il a été renommé. +
-    * MD **OK**+
-===== Retours de l'équipe de Besançon sur Électrique-Recalcul-Persistance-Annotation =====+  * <del>le graphique en mode densité est à nouveau buggé</del>  
 +    * **SJ: fixé temporairement** : forçage du mode R quand on passe en "Densité" et forçage du mode JFC quand on repasse en "Cumulatif". Il faut implémenter le graphe "Densité" en mode JFC, voir ticket dédié] 
 +  * changer une requête dans la zone multiple ne passe pas l'éditeur en dirty, le bouton "compute" reste donc disabled et la seule solution pour mettre à jour et d'appuyer sur entrée 
 +    * **MD corrigé**
-Retours issus de la réunion à Besançon du X/X/2018.+SLH 2019-02-11
-=== Paramètres électriques ===+  * dans la Progression, clic gauche ou double-clic gauche n'importe où dans la fenêtre (éditeur) provoque une stacktrace comme la suivante : <code>!ENTRY org.eclipse.ui 4 0 2019-02-11 17:44:27.791  
 +!MESSAGE Unhandled event loop exception  
 +!STACK 0  
 +java.lang.IndexOutOfBoundsException: Index: 104, Size: 81  
 +    at java.util.ArrayList.rangeCheck(ArrayList.java:657)  
 +    at java.util.ArrayList.get(ArrayList.java:433)  
 +    at org.jfree.data.xy.XYSeries.getRawDataItem(XYSeries.java:634)  
 +    at org.jfree.data.xy.XYSeries.getX(XYSeries.java:645) 
 +</code> 
 +    * **MD corrigé** 
 +     
 +SLH 2019-02-11
-(calcul automatique des résultats à chaque changement de paramètre)+  * dans la Progression, la suppression de deux requêtes (pour éclaircir le graphique par exemple) décale les couleurs des courbes encore affichées (on commence toujours par bleu, rouge, etc.)\\ 
 +C'est dommage car ça gêne la lecture -> si possible, ne pas changer l'allocation des couleurs des courbes qui restent présentes, et récupérer les couleurs des courbes retirées au fur et à mesure de l'ajout de nouvelles requêtes/courbes  
 +    * **SJ: reporté, peut-être pour la 0.8.1, voir ticket [[http://forge.cbp.ens-lyon.fr/redmine/issues/2504|ticket #2504]]**
-  * rendre toutes les commandes électriques semble une bonne chose du point de vue des utilisateurs +SLH 2019-02-11
-    * voir ensuite si on peut maintenir cela techniquement +
-  * remarques : +
-      * si on décide de rendre des commandes électriques et d'autres non électriques, on pourrait mettre un Bouton Toggle sur chaque commande pour activer ou non le mode électrique ou non + pref globale par commande +
-        * SLH (31/10) : ça ne me semble pas bon parce que ça voudrait dire que certaines commandes ne fonctionnent pas bien en électrique, par design. Auquel cas autant ne pas faire d'électrique du tout. Par contre, on peut faire un paramètre global unique "Activer le mode électrique [oui/non]", ce qui serait utile par exemple comme paramètre de corpus pour le grands corpus qui supporteraient mal les commandes électriques +
-      * même si on rend toutes les commandes électriques, ce bouton et les prefs globales par commandes pourraient être utiles ? +
-        * SLH (31/10) : je ne comprends pas la remarque. Ça correspond à mettre toutes les commandes électriques par défaut et permettre d'en débrancher à la demande, ce qui revient au cas de départ +
-      * on pourrait aussi utiliser un code couleur pour électriques/non électriques +
-      * changer code couleur des commandes électriques ou non (titre onglet ou background color ? ou autre ?) +
-      * la cooccurrence semble une commande pouvant être longue à paramétrer donc peut-être que le mode électrique n'est pas adapté ? +
-        * si on reste en électrique et à propos de la remarque de BP : +
-          * faire une pref d'hampan pour word, ex. tailles des contextes à 10 +
-            * SLH (31/10) : une valeur par défaut comme préférence globale ? +
-          * faire une pref d'hampan pour structure, ex. tailles des contextes à 1 +
-          * changer la taille lorsque l'on passe de word à structure et vice versa +
-            * SLH (31/10) : cela veut dire qu'il y a de la dépendance entre paramètres dans leur saisie. Y-a-t'il des précédents dans TXM ? +
-      * attention : mettre une pop up au changement d'unité structurelle de la Table Lexicale si elle a été modifiée (lignes supprimées, fusionnées, etc.) pour prévenir l'utilisateur qu'il va perdre ses changements ou bien lui proposer d'exporter la table +
-        * SLH (31/10) : changement de propriété de mot plutôt ? +
-          * c'est valable pour tout changement de nature d'une table issue de Table lexicale, Index de partition etc. après édition de cette table +
-          * la proposition d'export ou de sauvegarde rejoint la problématique du recalcul d'une table lexicale éditée+
-=== Recalcul automatique en cascade ===+  * dans la Progression, le clic sur le bouton "Open Chart Properties"  des paramètres de rendu ne fait qu'afficher ceci dans la console (pas de propriétés accessibles) :\\  
 +<code> 
 +OpenJFCChartPropertiesEditor.execute(): Can not open chart properties interface for the current chart engine. 
 +</code> 
 +      * **MD message rectifié**
-(calcul automatique des résultats enfants si on modifie un résultat parent, ex. : modifier une table lexicale va recalculer automatiquement une spécif et/ou une AFC qui est en dessous)+SLH 2019-02-11
-  * le maintien de la cohérence de la branche de résultats semble très utile, recalcul ascendant, descendant et des noeuds frères +  * dans la Progression, le clic sur le bouton "Show/Hide title"  des paramètres de rendu ne fait qu'afficher ceci dans la console (le titre est toujours là) :\\  
-    * à confirmer après la prise en main de l'alpha+<code> 
 +java.lang.ClassCastException: org.jfree.chart.JFreeChart cannot be cast to java.io.File  
 +    at org.txm.chartsengine.r.core.RChartCreator.updateChart(RChartCreator.java:32)  
 +</code> 
 +    * **SJ: corrigé pour les moteurs JFC et R **
-=== Persistance ===+BP 2019-03-05 (Ubuntu 16.04, TXM 0.8.0.1826, 0.8.0.201902271548)
-  * l'astérisque n'est vraiment pas intuitive (on croit que ce sont les résultats qui vont être conservés alors que c'est l'inverse) => repartir sur une bullet/puce lorsque l'on clique sur "Conserver" +  * Dans la zone de paramètres, dans la partie de réglage de l'"unité structurelle et propriété", le champ pour afficher la valeur de la propriété est de largeur quasi nulle : on voit ce qu'on peut choisir quand on affiche sur la flèche, mais une fois le choix fait on ne voit plus le nom de la propriété qui a été choisie. 
-    * SLH (31/10) : dans ce cas comment différencier les résultats temporaires non sauvegardés (sans marque) des résultats persistents de sessions précédentes (sans marques) +    * SJ: non reproductible sous Windows 7 et Ubuntu 14 ; reproductible sous VM Ubuntu 18.10, en cours de correction 
-  * TXM étant aussi un logiciel d'exploration, il y a plus d'"essais" que de choses à conserver ainsi la pref d'auto-sauvegarde ne devrait sans doute pas être activée par défaut +      * **MD corrigé**
-    * SLH (31/10) : ça devrait déjà être le cas dans l'ALPHA 3+
-=== Annotation ===+SLH 2019-03-24 (Ubuntu 18.04) 
 +  * la Progression en densité de 3 mots dans VOEUX provoque une stacktrace (la progression s'affiche correctement) : 
 +<code> 
 +Progression de <[[word="France"], [word="pays"], [word="Europe"], [word="monde"]]> dans le corpus VOEUX... 
 +Sauvegarde du graphique dans le fichier : /home/sheiden/TXM-0.8.0/results/progression_density6712310819957726674.svg.
-  * VL, MB sont très intéressées par l'utilisation des annotations dans un futur très proche +!ENTRY org.eclipse.ui 4 0 2019-03-23 17:35:58.671 
-    * SLH (31/10) : j'ai fourni par mail à VL toutes les infos disponibles sur les différents outils d'annotation à ce stade. Il faut voir comment organiser des retours éventuels :\\ <code>[extrait du mail] +!MESSAGE Unhandled event loop exception 
-*Annotation URS en plein texte*+!STACK 0 
 +java.lang.NullPointerException 
 +    at java.awt.Container.addImpl(Container.java:1095) 
 +    at java.awt.Container.add(Container.java:419) 
 +    at org.txm.chartsengine.rcp.swt.SwingChartComposite.loadChart(SwingChartComposite.java:877) 
 +    at org.txm.chartsengine.rcp.swt.ChartComposite.loadChart(ChartComposite.java:91) 
 +    at org.txm.chartsengine.rcp.editors.ChartEditor$2.run(ChartEditor.java:460) 
 +    at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:233) 
 +    at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:144) 
 +    at org.eclipse.swt.widgets.Display.syncExec(Display.java:5535) 
 +    at org.txm.chartsengine.rcp.editors.ChartEditor.loadChart(ChartEditor.java:457) 
 +    at org.txm.chartsengine.rcp.editors.ChartEditor.updateEditorFromResult(ChartEditor.java:302) 
 +    at org.txm.rcp.editors.TXMEditor.refresh(TXMEditor.java:1059) 
 +    at org.txm.rcp.editors.TXMEditor$4$2.run(TXMEditor.java:930) 
 +    at org.eclipse.ui.internal.PendingSyncExec.run(PendingSyncExec.java:58) 
 +    at org.eclipse.ui.internal.UILockListener.doPendingWork(UILockListener.java:168) 
 +    at org.eclipse.ui.internal.UISynchronizer.lambda$0(UISynchronizer.java:150) 
 +    at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:37) 
 +    at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:182) 
 +    at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4577) 
 +    at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4186) 
 +    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1150) 
 +    at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336) 
 +    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1039) 
 +    at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:153) 
 +    at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:680) 
 +    at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336) 
 +    at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:594) 
 +    at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148) 
 +    at org.txm.rcp.Application.start(Application.java:240) 
 +    at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) 
 +    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) 
 +    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) 
 +    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388) 
 +    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243) 
 +    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
 +    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
 +    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
 +    at java.lang.reflect.Method.invoke(Method.java:498) 
 +    at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:653) 
 +    at org.eclipse.equinox.launcher.Main.basicRun(Main.java:590) 
 +    at org.eclipse.equinox.launcher.Main.run(Main.java:1499) 
 +    at org.eclipse.equinox.launcher.Main.main(Main.java:1472) 
 +392, 153, 141, 139 position(s). 
 +</code> 
 +  * **SJ: non reproductible, reporté, voir ticket [[http://forge.cbp.ens-lyon.fr/redmine/issues/2527]]**
-L'annotation URS de DEMOCRAT est en cours de validation par des utilisateurs, surtout des stagiaires de master, depuis début 2017. +===== Commande Table lexicale =====
-L'extension Analec (qui doit être renommée 'Annotation URS') est suffisamment mûre pour être disponible pour TXM 0.7.9 depuis début 2018.+
-Sa documentation est désormais intégrée au manuel TXM +BP 2019-03-22 (Ubuntu 16.04, TXM 0.8.0 beta 4, 0.8.0.1913, 0.8.0.201903181603) 
-http://textometrie.ens-lyon.fr/html/doc/manual/0.7.9/fr/manual53.xhtml#toc285 +  * Après fusion de lignes, la 1ère colonne est retriée, mais du coup se trouve en ordre alphabétique inverse : il faudrait peut-être plutôt trier 2 fois ? 
-[ou http://textometrie.ens-lyon.fr/files/documentation/Manuel%20de%20TXM%200.7%20FR.pdf pour le manuel PDF+    * **MD reporté** [[http://forge.cbp.ens-lyon.fr/redmine/issues/2560]
-Elle explique comment installer l'extension Analec et comment annoter en unités URS. +  * Quand on clone une table lexicale, cela perd les fusions de lignes qu'on avait effectuées avant clonage : bien le noter dans la doc car ce n'est pas forcément ce à quoi on s'attend
-Elle est très perfectible, donc n'hésitez pas à faire des propositions+    * **MD corrigé** un warning est maintenant affiché dans la console et voir aussi [[https://forge.cbp.ens-lyon.fr/redmine/issues/2545]]
-Elle n'intègre pas encore la description de tous les outils d'exploitation des annotations URS disponibles, mais un certain nombre de recettes de validation les présentent déjà, comme celle-ci : +
-https://groupes.renater.fr/wiki/txm-info/public/spec_exploitation_annotation/spec_urs_mesures2#recette_33 +
-Il y a également une section de proto-documentation dans une autre page du wiki du projet : +
-https://groupes.renater.fr/wiki/txm-users/public/umr_lattice/democrat/public/manuel_utilisation_extension_analec#exploiter_des_annotations_analec_avec_des_macros+
-Il y aura une dernière campagne de développement/consolidation de l'extension URS, dont le contenu est pratiquement établi ici +BP 2019-04-02 (Ubuntu 16.04, TXM 0.8.0, 0.8.0.1928, 0.8.0.201903221605) 
-http://forge.cbp.ens-lyon.fr/redmine/projects/txm/issues?query_id=64 +  * [plutôt une feature] Ce serait commode que le premier tri obtenu en cliquant sur une colonne de fréquences soit décroissant (dans la TL, mais aussi ailleurs quand ce n'est pas le tri initial : spécifs, cooc). 
-[on devrait notamment aider à exploiter ces annotations avec les outils habituels de TXM]+    * **MD reporté** [[http://forge.cbp.ens-lyon.fr/redmine/issues/2561]]
-*Annotation par Concordances*+===== Commande AFC =====
-L'annotation de séquences de mots par le biais de Concordances est disponible depuis TXM 0.7.9. +JCD 2019-03-20
-Documentée dans le manuel de TXM depuis 0.7.9 : +
-http://textometrie.ens-lyon.fr/html/doc/manual/0.7.9/fr/manual50.xhtml+
-Il y aura une troisième fonctionnalité d'annotation par Concordances dans TXM 0.8.0 : +  * "que ce soit dans AFC ou CAH, lorsqu’on effectue un zoom sur le graphique, tous les points sont superposés au  centre du graphique" 
-- annotation/correction de propriétés de mots par le biais de Concordances+    * **SJ: corrigé en repanssant à Java jre-8u151-macosx-x64** bug de Java > 1.8u151 faisant que Java ne reçoit pas les bons événements lors du défilement sur un touchpad Mac [[http://forge.cbp.ens-lyon.fr/redmine/issues/2519|#2519]]
-L'ALPHA 3 de TXM 0.8.0 permet de tester la correction de pos et de lemmes, ou de toutes autres propriétés de mots, par concordances dans les textes.</code>+SLH 2019-02-11
-===== Retours de l'équipe de Lyon sur Électrique-Recalcul-Persistance (2018-10-12) =====+  * dans le tableau des lignes d'une AFC, les raccourcis flèche-haut et flèche-bas ne fonctionnent plus (mouvement de la sélection vers le haut ou le bas).  
 +    * **SJ: bug spécifique à Linux, en cours de correction**
-La démo a été faite sur Windows+SJ: 
 +  * les préférences par défaut fmin/vmax de la page de pref AFC ne fonctionnent plus. Ce sont celles de la page de pref de la Table Lexicale qui sont utilisées. 
 +  * **MD à discuter** pour TXM 0.8.1 [[http://forge.cbp.ens-lyon.fr/redmine/issues/2510|#2510]]
-=== Paramètres électriques ===+BP 2019-03-22 (Ubuntu 16.04, TXM 0.8.0 beta 4, 0.8.0.1913, 0.8.0.201903181603) 
 +  * le menu pour choisir le plan à visualiser est figé (on n'arrive pas à l'ouvrir pour sélectionner le plan 1x3 par exemple). 
 +    * **SJ: corrigé**
-mode électrique = la fin de saisie d'un champ (voir le scénario de décision de fin de saisie) déclenche le recalcul ou la maj du résultat+SLH 2019-03-24 (Ubuntu 18.04) 
 +  * le recalcul après relancement de TXM d'une AFC des colonnes conservée provoque une stacktrace (le plan d'AFC s'affiche correctement): 
 +<code> 
 +Création de la fenêtre de l'AFC 
 +TXMEditor.createPartControl(): can not create the editor for result null. 
 +Stacktrace: 
 +[1]             org.txm.rcp.editors.TXMEditor.createPartControl  TXMEditor.java, 484 
 +[2]           org.txm.ca.rcp.editors.CAEditor.      createPages  CAEditor.java, 173 
 +[3]         org.txm.ca.rcp.handlers.ComputeCA.          execute  ComputeCA.java, 177 
 +[4]  org.txm.rcp.handlers.BaseAbstractHandler.   executeCommand  BaseAbstractHandler.java, 240 
 +[5]  org.txm.rcp.handlers.BaseAbstractHandler.   executeCommand  BaseAbstractHandler.java, 164 
 +[6]   org.txm.rcp.views.corpora.CorporaView$3.      doubleClick  CorporaView.java, 361 
 +[7]                   org.txm.rcp.Application.            start  Application.java, 240 
 +java.lang.NullPointerException 
 +    at org.txm.chartsengine.rcp.swt.AdvancedChartEditorToolBar.<init>(AdvancedChartEditorToolBar.java:53) 
 +    at org.txm.chartsengine.rcp.editors.ChartEditor._createPartControl(ChartEditor.java:186) 
 +    at org.txm.rcp.editors.TXMEditor.createPartControl(TXMEditor.java:430) 
 +    at org.eclipse.ui.part.MultiPageEditorPart.addPage(MultiPageEditorPart.java:241) 
 +    at org.eclipse.ui.part.MultiPageEditorPart.addPage(MultiPageEditorPart.java:211) 
 +    at org.txm.ca.rcp.editors.CAEditor.createPages(CAEditor.java:173) 
 +    at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:348) 
 +    at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.createPartControl(CompatibilityPart.java:151) 
 +    at org.eclipse.ui.internal.e4.compatibility.CompatibilityEditor.createPartControl(CompatibilityEditor.java:99) 
 +    at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.create(CompatibilityPart.java:355) 
 +    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
 +    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
 +    ... 
 +    </code>
-  * scénarios électriques exprimés:  +  * **SJ: corrigé**
-    * BP : certain paramètres ne sont pas électriques +
-      * il faut discuter de ces paramètres +
-    * SJ : tous les paramètres sont électriques +
-  * solution +
-    * ajouter une préférence pour activer/désactiver le "mode tout électrique" (mode SJ) des paramètres de résultats +
-      * par défaut : désactiver ? (à cause des gros corpus ? à discuter ?) +
-    * recenser tous les paramètres non-électriques (BP) +
-    * finaliser le scénario+
-Discussion: +===== Commande CAH =====
-  * mode MD : les paramètres sont électriques après avoir lancé le calcul une première fois +
-    * BP : c'est plus souvent pertinent qu'au début (on est plus souvent dans un scénario de retouche et ajustement) mais ce n'est quand même pas toujours le cas. +
-  * ajouter des paramètres électriques groupés/complexes (ex : réglage du contexte de la cooc) +
-  * voir la notion d'arguments de résultats (changement de la requête) VS paramètres de résultats (affichage de chart) VS modifications de résultats (suppression lignes) +
-  * évolution du bouton %%(|>)%% pour qu'il drive le mode électrique : %%(|>)%% électrique -> %%(||)%% non-électrique -> %%(|>)%% électrique +
-  * ajouter une préférence pour activer ou pas le (ou la tentative pour être + précis) calcul d'un résultat à l'ouverture dans son éditeur+
-=== Recalcul automatique en cascade ===+SLH 2019-02-11
-Recalcul automatique alpha3 = +  * l'onglet de l'éditeur de CAH n'est pas externalisé  
-  * tous les paramètres d'un résultat sont modifiables +    * **MD corrigé**
-  * le résultat est recalculé entièrement seulement pour certains paramètres +
-  * tous les descendants d'un résultats sont alors recalculés +
-  * si un enfants modifie le paramètre de son parent, alors ses frères (et descendants) seront recalculés (AFC, Spécificités, CAH+
-  * justifications :  +
-    * MD (à reformuler) la propagation est totale, il n'y a pas de désynchronisation entre les résultats+
-Recalcul automatique MD = +SLH 2019-02-11
-  * tous les paramètres d'un résultat sont modifiables +
-  * le résultat est recalculé entièrement seulement pour certains paramètres +
-  * tous les descendants d'un résultat sont alors recalculés +
-  * les résultats intermédiaires ne sont pas affichés (ne sont donc pas re-paramétrable et n'ont qu'un seul descendant) +
-  * un enfant ne modifie pas de paramètre de son parent sauf si il est enfant unique et que son parent n'est pas visible (ex : AFC crée depuis une partition, la LT n'est pas affichée) +
-  * justifications :  +
-    * MD (à reformuler) on limite la propagation+
-Recalcul automatique SLH = +  * faire une CAH ou une AFC avec la propriété 'id' provoque la stacktrace ci-dessous -> retirer la propriété 'id' de la liste des propriétés.  
-  * reprend le mode Alpha3 ou MD et ajoute : +    * **MD corrigé** 
-    * on peut geler un résultat et sa descendance à la demande +    * SJ: je pense qu'il faut une fois pour toute stocker la liste des propriétés CQP de type "interne" et qui ne doivent pas forcément être affichées pour l'utilisateur lambda. L'état actuel est : ça dépend des commandes et tout est codé en dur avec des tests sur String un peu éparpillés dans les différentes commandes. 
-    * un parent ne peut pas modifier un descendant gelé +      * SH : il existe déjà une infrastructure pour gérer le comportement d'une commande par rapport à des propriétés de structures (et non de mots) : les métadonnées de textes pour la commande "[[https://groupes.renater.fr/wiki/txm-info/public/listes_de_textes|Liste des textes]]" implémentée seulement dans le portail 
-    * pour faire une variante d'un calcul gelé, on le clone sans ses descendants+        * le paramétrage du comportement se fait directement dans le fichier import.xml, pas d'UI à ce stade 
 +          * les éléments XML concernés doivent être documentés dans le manuel d'administrateur de portail 
 +        * il y a différents types de comportements propres à la commande : afficher ou pas, ordre d'affichage entre propriétés, types de tris, etc. 
 +        * on pourrait faire évoluer cela en : 
 +          * prenant en charge des propriétés de mots, en plus de propriétés de textes, pour certaines commandes 
 +          * créant une interface pour simplifier le paramétrage au sein, ou accessible depuis, le formulaire d'import d'un corpus 
 +          * les paramètres de comportements de commandes seraient gérés comme des propriétés de corpus 
 +    * SJ: mais en fait je ne comprends pas pourquoi supprimer la propriété "id" ? "base", etc. OK mais "id" ? 
 +      * SH : dans le contexte de la CAH, tout ce que dit mon retour est que ça bugge si on utilise la propriété "id" (ça n'a pas forcément de sens non plus). J'imagine que ne pas donner accès à cette propriété est une façon d'éviter de provoquer le bug. On peut aussi laisser l'utilisateur se planter (pas un bug du coup). 
 +      * SJ: je viens de comprendre qu'il n'y a pas d'intérêt à faire une Table sur 'id'. En revanche je ne sais pas pourquoi la table plantait. Ca devrait créer une tableau avec les "id" et des 1, 0, 0, 0 etc. / 0, 1, 0, 0 etc. Ca relance aussi la question des tests manquants sur des tables de contingences n'étant pas une matrice valide pour la CA et la CAH, lignes ne contenant pas 3 valeurs non nulles, etc. (indépendamment du nombre de colonnes/lignes) 
 +        * **MD discussions en cours** choix probablement après la 0.8.0
-Recalcul automatique BP = +JCD 2019-02-13
-  * dès qu'un résultat a des enfants les paramètres ne sont pas modifiables +
-  * un enfant ne modifie pas de paramètre de son parent +
-  * pour faire une variante d'un calcul, on le clone sans ses descendants +
-  * justifications : +
-    * les calculs propagés ne sont a priori pas toujours bien définis (typiquement dans le cas du changement de la propriété d'analyse lorsqu'on travaille sur une sélection, par ex. passage de graphies en lemmes ou réciproquement). Du coup ce n'est pas clair : quelquefois on ne fait rien ? ou on fait quelque chose d'incomplet, d'approximatif ? comment l'utilisateur pourra-t-il comprendre ce qui s'est passé ? si on fait quelque chose de simplifié, n'aurait-il pas mieux valu que l'utilisateur le fasse lui-même (pas compliqué et meilleure perception du traitement) ? +
-    * le recalcul automatique met à jour des résultats intermédiaires dont la pertinence n'est pas vérifiée par l'utilisateur : l'utilisateur ne perçoit pas forcément la portée de sa modification, or il est important de bien maîtriser toute la chaîne de traitements pour interpréter le résultat, cf. ex. du choix de conception d'Hyperbase qui obligeait l'utilisateur à calculer et afficher les contextes des mots dont on allait ensuite repérer les cooccurrents (fonction Thème). +
-    * de même avec cette portée très puissante, il y a vraiment le risque d'écraser des résultats précédents, des intermédiaires, qu'on voulait garder (ex. retouche de l'AFC => on perd la table lexicale qu'on avait retravaillée en fusion/suppression de lignes, sans forcément s'en rendre compte...). Et on n'a pas de de fonction annuler (défaire, retour arrière, contrôle-z). +
-    * le clonage d'un résultat pour le modifier est de toutes façons utile à prévoir (cas de figure où on veut tester plusieurs variantes en parallèle pour les comparer). +
-    * le principe de cohérence qui voudrait appliquer une rétropropagation voudrait remplacer le chemin suivi par un autre chemin, analogue mais réajusté. Cependant, c'est un chemin artificiel. Ce qui a du sens c'est le "vrai" chemin, qui correspond à des étapes choisies, comprises et parcourues. A l'utilisateur de décider s'il veut recommencer autrement (et construire lui-même un autre chemin). Une question est alors plutôt la manière de rendre compte au niveau de l'interface du chemin suivi (par ex., faut-il marquer le lien entre des clones et comment ?).+
-Solution : +  * faire une CAH en Mac OS X 10.10 ou 10.12, bloque le calcul (le moniteur indique que TXM ne répond pas). Le job affiche "Calcul de 2 clusters etc."; la console : 
-  * ajouter une préférence pour activer/choisir le "mode de calcul en dépendance+<code> 
-  * choisir le mode par défaut+Calcul de la CAH... 
 +Sauvegarde du graphique dans le fichier : ... 
 +</code>
 +  * SJ: <del>bug reproduit 1 fois sous Mojave. Je n'arrive pas à le reproduire de nouveau. Il y a un deadlock, la première hypothèse étant un eval R qui ne retourne pas car la dernière ligne du log et l'envoi de la commande de AHC à R.</del> 
 +    * **SJ: normalement corrigé, à retester en profondeur**
-=== Persistance ===+FB 2018-03-07 
 +  * une erreur lors de la classification qui fonctionne dans l'ancienne version mais me renvoie vide dans la nouvelle : SVG file /home/flora/TXM-0.8.0/results/ahc165681592925985331.svg is empty. 
 +Stacktrace: [ 1]  org.txm.chartsengine.svgbatik.rcp.swt.SVGComposite.       loadSVGDocument  SVGComposite.java, 59 [...] 
 +    * **SJ: voir ticket [[http://forge.cbp.ens-lyon.fr/redmine/issues/2521]]**
-  * Mode de conservation des résultats : 
-    * mode Bezak : ne pas conserver par défaut, mettre en évidence les résultats conservés avec un bullet vert  
-    * mode SLH (Alpha3) : ne pas conserver par défaut, mettre en évidence les résultats non sauvés avec une astérisque 
-      * le mode BP est celui des Bisontins ou de Serge, à savoir par défaut un résultat est caduque. Mais l'idée ensuite (celle de Serge) c'est d'éviter d'alourdir typographiquement les résultats conservés ; par contre l'astérisque n'est pas forcément bien comprise par tous. Chercher un autre mode typographique (italique, grisé,...?) qui signale la caducité du résultat de façon plus intuitive tout en alourdissant le moins possible l'affichage. 
-    * mode CG : conserver par défaut, ne mettre aucune mise en évidence (devient inutile) et retirer le choix "conserver" du menu contextuel de la vue Corpus (devient inutile, car on peut supprimer) 
-Que faire des modifications manuelles de résultat (ex: suppression de lignes dans la concordance et table lexicale) ?+===== Commande Spécificités =====
-Solution : +BP 2019-03-19 (Ubuntu 16.04, TXM 0.8.0 beta 4, 0.8.0.1913, 0.8.0.201903181603) 
-  * oublier les modifications à la fin de la session (Alpha 3+  * Si on lance un calcul de spécificités directement sur une partition, les paramètres par défaut (qu'on ne voit pas si on ne va pas les chercher) ne sont plus les mêmes qu'en 0.7.9, avant on avait juste Fmin > 1, maintenant on a aussi un Vmax=200. Or cela a un gros impact et sur les valeurs d'indice, et sur les mots présents dans le tableau des résultats, si l'utilisateur ne se méfie pas cela peut être assez trompeur. J'imagine que le seuil de Vmax a dû être fixé pour tenir compte du fait que les corpus actuels peuvent être vraiment très (trop) gros pour lancer le calcul par défaut sur tous les mots (Fmin > 1 voire Fmin > 0). Ce qui pourrait être envisagé (en le documentant ?), ce serait de calculer les spécifs pour tous les mots mais de créer une ligne #RESTE# regroupant les plus basses fréquences si le calcul est jugé trop lourd : ainsi, les tailles des parties sont calculées en prenant bien en compte tous les mots, et la plupart des mots que l'utilisateur peut vouloir chercher sont présents dans le tableau. 
-  * sauver/charger automatique entièrement le résultat (pas que les paramètres +    * **SJ** : c'est un effet de bord, comme pour l'AFC, les préférences par défaut sont celles de la commande Table Lexicale. Il faudrait sans doute dissocier ces prefs pour les commandes directs qui ne passent pas par la table lexicale et la masque (voir ticket [[http://forge.cbp.ens-lyon.fr/redmine/issues/2510]]
-  * export/import à la demande (cas table lexicale+    * **BP 2019-04-03** : en attendant, que penseriez-vous de régler les préférences de la table lexicale à Fmin = 1 et Vmax = 9999999..., autrement dit pas de filtrage en pratique ? Le risque c'est de planter TXM pour les (très) gros corpus, mais dans ce cas les utilisateurs chercheront une solution et iront régler la préférence de façon pertinente pour leur cas et en connaissance de cause ? Et il me semble que cet effet négatif serait moins important/fréquent que celui de la mauvaise interprétation d'un calcul de spécificité où l'ensemble de référence est très différent de celui qu'on croit. 
-  * ajouter une propriété interne aux objets pour coder la suppression (= les manipulations sont enregistrées)+    * **BP 2019-04-04** : même quand on passe par une table lexicale, cette application des préférences Fmin=2 & Vmax=200 reste gênante sinon "dangereuse". Je crée un index sur partition, je le transforme en table lexicale avec l'option marges = tous les mots recensés par l'index, et cela me crée une table lexicale avec seulement les 200 mots les plus fréquents, donc seulement une partie de mon index. Ce n'était pas le cas en 0.7.9 (la préférence pour une Fmin à 2 n'intervenait pas à ce stade). Et comme la table n'est pas triée de la même façon (alphabétiquement au lieu de hiérarchiquement), le fait que des lignes aient été "perdues" n'apparaît pas de façon évidente. 
 +    * **BP 2019-04-04** : l'enjeu, c'est d'éviter que même les spécificités "de base" soient "compliquées" à obtenir (c'est le genre de calcul que les autres logiciels offrent en un clic), ou massivement "fausses" (l'utilisateur ne comprend pas ou ne voit pas les seuils, qui ne sont généralement pas bons avec les valeurs par défaut 2 / 200). Du coup pour moi c'est un point qui serait assez urgent (cela ne sera peut-être pas possible pour la 0.8.0, mais ce serait alors pour une des premières mises à jour). Un simple (?) changement des paramètres par défaut pourrait déjà régler l'essentiel il me semble. 
 +    * **SJ 2019-04-08** : je suis en train de m'orienter vers ceci, dans les cas des commandes "raccourcies" (celles non appelées sur la Table Lexicale) : 
 +      * on laisse fmin=2/vmax=200 pour la commande table lexicale, donc aussi pour la CA et CAH 
 +      * on force fmin=1/vmax=9999999 pour la commande Spécificités 
 +      * pour la commande Table Lexicale depuis Index de partition, on transmet le fmin et vmax de l'index à la table lexicale
-=== Propositions d'amélioration de l'interface ===+BP 2019-04-04 (Ubuntu 16.04, TXM 0.8.0, 0.8.0.1928, 0.8.0.201903221605) 
 +  * Bug concernant le diagramme en bâtons de spécificités lorsque plusieurs lignes sont sélectionnées : la légende ne fait pas correspondre les bons mots (lignes) aux bons bâtons. En fait, dans la légende qui s'affiche à droite, c'est comme si l'ordre (vertical) des mots et l'ordre des couleurs étaient inversés l'un par rapport à l'autre, je crois que par exemple si on lit les couleurs de haut en bas et les mots de bas en haut on retrouve les bonnes correspondances couleur-mot (première couleur = dernier mot, 2e couleur = avant-dernier mot, etc.). Cependant, cela ne se produit pas systématiquement, mais je n'ai pas identifié ce qui pourrait être différent dans les situations où cela arrive vs où cela n'arrive pas. 
 +    * **MD reporté ** [[http://forge.cbp.ens-lyon.fr/redmine/issues/2562]] 
 +    * BP 2019-04-12, BP 2019-04-15 (Ubuntu 16.04, TXM 0.8.0.2009, 0.8.0.201904121205) Il me semble que je peux préciser le diagnostic : 
 +      * les bâtons sont triés selon l'ordre alphabétique des unités sélectionnées (tri alphabétique de la première colonne), ou l'ordre inverse, en tout cas l'ordre des bâtons est stable quel que soit l'ordre d'affichage des lignes dans le tableau ; 
 +      * la légende est ordonnée selon l'ordre des lignes affichées dans le tableau au moment du lancement de la commande (par ex. selon un tri hiérarchique sur un indice de spécif. pour une colonne) 
 +      * (Rq. au passage : si l'on a fait une sélection de lignes et que l'on change l'ordre des lignes, la sélection ne suit pas le mouvement des lignes, elle reste fixe pendant que les lignes bougent.) 
 +      * Rq. principale : j'espère que ce diagnostic plus précis pourra aider à corriger le bug rapidement car il est important (il peut vraiment conduire à de grosses erreurs d'analyse). 
 +      * **MD corrigé**
-  * Toolbar des éditeurs +===== Barre de statut =====
-    * augmenter le contraste des boutons : surtout Windows, par exemple le bouton "paramètres" de la toolbar des TXMEditors quand le bouton est activé +
-    * déplacer le bouton "Play" à la fin des boutons de la toolbar des éditeurs +
-  * auto-documentation de l'interface  +
-    * prioritaire : vérifier que tous les flyover soient corrects +
-    * éventuellement : renseigner les titres de boutons et ajouter une préférence pour activer l'affichage des titre de boutons dans les toolbars des TXMEditors (ex : le bouton compute %%(|>)%% -> %%Calculer (|>)%%) +
-  * améliorer l'ergonomie du widget PropertiesSelector (le label "editer" sur le bouton  prête à confusion) +
-    * prioritaire : "Editer" -> "..." +
-    * prioritaire : "Propriétés :" -> "Propriétés" +
-    * éventuellement : scénarisation en widget extension de combo (pour gérer l'ordre de la sélection) : lorsque l'on clique sur la flèche v, une pop-up est ouverte (comme dans le portail) +
-  * connaître les paramètres d'un résultat : +
-    * prioritaire : Ajouter une commande "Propriétés" à tous les résultats (affiche dans un éditeur les paramètres dans une page HTML + 2 boutons Exporter/Importer) +
-    * éventuellement : Ajouter une vue "Propriétés" qui permet de voir, exporter et importer des paramètres +
-  * confusion sur le role des boutons "Tri" et "Search" des concordances  +
-    * retirer le bouton "Tri" et détecter dans le compute de la concordance si il faut recalculer toute la concordance ou pas +
-      * note MD: dans TXM 0.7.9 la concordance est systématiquement recalculée entièrement, mais on peut à présent détecter si il suffit de maj les lignes ou si il faut maj la sélection de la concordance +
-  * amélioration des éditions +
-    * remonter le bouton de choix des éditions de la commande Édition dans la zone des paramètres +
-  * améliorer la relation entre la vue Corpus et les éditeurs +
-    * lorsque qu'un éditeur TXMEditor est activé,  +
-      * faire le focus (déplacer le viewport) sur le résultat dans la vue Corpus +
-      * mettre en évidence en "gras" dans la vue Corpus+
 +SJ:
 +  * la suppression du texte de la barre de statut ne se fait plus au bout de X secondes, ça reste par exemple sur "Calcul de 2 clusters of columns..."
 +    * le plus simple serait de linker le contenu de la barre avec la Task name du JobJandler de TXMEditor.compute()
 +      * **MD corrigé** la status line est vidée à la fin du job
 +    * SH: le message "Calcul de 2 clusters of columns..." est du franglais, il devrait être :
 +      * EN: "Calculus of 2 clusters of columns..."
 +      * FR: "Calcul de 2 classes de colonnes..."
 +      * **MD corrigé**
-=== bugs (à traiter ou déplacer)===+===== Visualisations Graphiques d'une manière générale =====
-  * La synoptique du Graal est cassée ? +SJ: 
-  * &lt;del>La saisie d'un caractère au clavier dans les spinners déclenchent un compute<del/> [SJ: fixé] +  * la version beta3 et les version antérieures souffrent de problèmes liés au focus des composants qui se comporte différemment selon les systèmes d'exploitation. Le passage à Eclipse 4.7 a par ailleurs changé de nouveau les comportements avec la mise à jour de SWT 
-    * &lt;del&gt;résolution : il y a des différences de comportement entre les OS à gérer&lt;/del+  * Bugs répertoriés induits par les problèmes de focus : 
-    * <del>scénario de décision de fin de saisie de valeur (voir la saisie des valeurs de propriétés URS) :</del> +    * **Windows :** 
-      * <del>au clavier la touche Entrée valide la valeur</del> [SJ: fait] +      * Menus contextuels =&gt; **OK** 
-      * prise de focus par un autre champ de l'éditeur [SJ: non fait. A faire ?] +      * Raccourcis clavier => **OK sauf CA et Eigenvalues** (note dev : le Context RCP ChartEditor se désactive à cause du MultiEditorPart, on peut voir par ailleurs que le menu contextuel sur la CA ou l'Eigenvalues ne contient pas les raccourcis) 
-  * la liste des propriétés de corpus est modifiée (la propriété word a été retirée) par un des éditeurs +      * Activation de l'Editeur au clic dans le graphique => **OK** 
-  * &lt;del>la maj de la courbe et de la légende de la progression ne fonctionne pas si on retire une requête&lt;/del&gt; [SJ: fixé] +      * Mise en évidence de points dans le nuage de points de l'AFC depuis la sélection au clavier des lignes du tableau &quot;Colonnes&quot; ou &quot;Lignes" => **OK** 
-  * la sélection d'une requête de l'historique du widget de requête ne déclenche pas de recalcul (mode électrique+      * <del>**BUG Win 7:** lancer une commande "non graphique" alors qu'un onglet avec graphique est déjà ouvert et actif repasse directement l'onglet avec graphique devant la nouvelle commande</del> **SJ: corrigé** 
-  * &lt;del>le bouton "tri" de la concordance ferme la zone des paramètres</del> [SJ: fixé] +    * **Linux :** 
-  * <del>les boutons de navigation dans les pages de la concordance ferment la zone des paramètres&lt;/del&gt; [SJ: fixé] +      * Menus contextuels => **OK** 
-  * <del>déplacer la préférence "toujours conserver les nouveaux résultats" dans la page Utilisateur (plutôt que Avancées)</del> [SJ: fait]+      * Raccourcis clavier => **KO mais marche parfois** (note dev : pourtant le Context RCP ChartEditor est bien activé même quand cela ne fonctionne pas. Attention : en plus les autres raccourcis, ex. F2 (rename) ne fonctionnent pas toujours non plus et cela semble se produire plus souvent lorsqu'on a un onglet de graphique ouvert) 
 +      * Activation de l'Editeur au clic dans le graphique => **OK** 
 +      * Mise en évidence de points dans le nuage de points de l'AFC depuis la sélection au clavier des lignes du tableau &quot;Colonnes" ou "Lignes" => **KO** 
 +        * note dev : je pense que les Listener clavier AWT et SWT sont exécutés en même temps. L'appui d'une flèche via AWT sélectionne la igne du tableau SWT et scroll jusqu'à elle ce qui doit bloquer la navigation par flèche dans le tableau 
 +        * note dev 2 : cela ne fonctionne que si la CA perd le focus 
 +      * **BUGS Ubuntu 18.10**: 
 +        * lancer une commande &quot;non graphique&quot; alors qu'un onglet avec graphique est déjà ouvert et actif passe TXM en "arrière-plan"/grisé  
 +        * quand on change d'onglets entre deux onglets de graphique, TXM passe en grisé et il faut recliquer une fois sur le titre de l'onglet pour l'activer 
 +        * le composant AWT ne perd jamais le focus au clic à l'extérieur du composant ce qui provoque divers bugs (Un fix pourrait être implémenté dans ChartEditor.onPartDeactivated() ?
 +    * **Mac :** 
 +      * Menus contextuels =&gt; **OK** 
 +      * Raccourcis clavier => **OK si l'éditeur est actif (sauf CA et Eigenvalues)**  
 +      * Activation de l'Editeur au clic dans le graphique => **OK** 
 +      * **BUGS Mac OS X Mojave 10.14**
 +        * le composant de l'AFC n'a jamais le focus donc la sélection de points dans le graphique au clavier ne fonctionnent pas 
 +        * quand on change d'onglets entre deux onglets de graphique, le focus reste dans le composant du premier onglet 
 +        * le composant AWT ne perd jamais le focus au clic à l'extérieur du composant ce qui provoque divers bugs (Un fix pourrait être implémenté dans ChartEditor.onPartDeactivated() ?) 
 +      * Mise en évidence de points dans le nuage de points de l'AFC depuis la sélection au clavier des lignes du tableau &quot;Colonnes&quot; ou "Lignes" => **OK**
-===== Retours sur les retours des 2 réunions =====+SJ: voir ticket [[http://forge.cbp.ens-lyon.fr/redmine/issues/1127]]
-== notes MD à réarranger&amp;reformuler ==+BP 2019-03-05 (Ubuntu 16.04, TXM 0.8.0.1826, 0.8.0.201902271548) 
 +  * Pour l'export des graphiques, il n'y a plus de préférence à régler ? Il faudra penser à indiquer dans le manuel comment le choix du format se fait (par le menu déroulant indiquant les types de fichiers en bas à droite de la boite de dialogue de sauvegarde, si j'ai bien compris). 
 +    * **SJ** : la préférence est dans "TXM\Avancé\Moteur de Graphiques\Format d'export par défaut" 
 +    * **BP** : OK, je l'ai bien trouvée et utilisée ; mais, pour faciliter la transition, si on permettait aussi le réglage à l'ancien endroit (TXM > Utilisateur &gt; Export) ?
-**A faire** 
-  * établir la liste des patterns par commande (et en fonction de l'état du résultat ?) : 
-    * titre des onglets d'éditeurs du résultat 
-    * tooltips des onglets d'éditeurs du résultat 
-    * message de la barre de statut lors du clic sur un résultat dans la vue corpus 
-    * labels des résultats dans la vue corpus 
-    * vérifier les préférences par défaut des commandes 
-**Paramètres électriques**+===== Liseuse SVG =====
-préférence de 2 modes de lancement de calcul : &quot;électrique&quot; et &quot;manuel" -> manuel par défaut+SJ: 
 +  * &lt;del&gt;l'ouverture direct de fichier SVG à partir d'un fichier .svg ne fonctionne plus&lt;/del> 
 +    *  **SJ: corrigé**
-séparer les paramètres électrisables des autres paramètres (arguments)+===== Import ===== 
 +====  XML-TEI Zero + CSV (nouveau nom de XTZ + CSV) ====
-les paramètres électrisables sont souvent des paramètres d'affichage mais ce n'est pas une condition suffisante (ex: fmin)+FB 2019-03-06
-Problématiques de chaque mode : +  * qu'est ce que cet import ? 
-  * Électrique +    * MD désolé c'est un renommage [SH: documenté dans la prochaine version du manuel de TXM (0.8 : [[https://sourceforge.net/p/txm/code/HEAD/tree/trunk/doc/user%20manuals/txm-manual-fr.odt?format=raw|télécharger le fichier ODT courant du manuel 0.8 en cours de rédaction]])]
-    * décision de la fin de saisie (entrée, perte/prise focus, etc.+
-    * changement d'ordres de grandeur (ex: cooc avec contexte de structure) +
-    * voir les paramètres qui ont été utilisé avec une vue / tooltip éditeur / commande propriétés / ..+
-  * Manuel +
-    * rendre compte que les paramètres ont été modifiés +
-    * avec enable/disable du bouton compute +
-    * "*" dans l'onglet de l'éditeur+
-Cas particulier des sous-corpus et partition qui sont toujours old-style+AL 2019-02-11
-**Recalcul automatique en cascade**+  * Le nom du corpus est défini au moment du choix du dossier. C'est bien, mais c'est dommage qu'il ne soit plus modifiable (ni même affiché sauf dans la console) par la suite ! 
 +    * **MD reporté** changer le nom est un peu délicat. En attendant, j'ai ajouté le nom du corpus dans l'onglet de la fenêtre d'import. [[http://forge.cbp.ens-lyon.fr/redmine/issues/2563]] 
 +  * Les préférences (plans textuels, langue, etc.) des sources 0.7.9 (stockées dans import.xml) ne sont pas reprises, elle ne semblent pas non plus persister d'une session à l'autre sous 0.8. C'est très inconfortable si le corpus a beaucoup de réglages spécifiques. 
 +    * **MD corrigé à confirmer** 
 +    * **AL correction confirmée TXM 0.8.0.201904161055** 
 +  * La langue d'annotation sélectionnée par défaut est "FR", or les fichiers .par disponibles après installation du TreeTagger sont "en.par", "fr.par" et "fro.par". Sous Linux, ça provoque une erreur, puisque TXM cherche le fichier "FR.par" 
 +    * **MD corrigé** 
 +  * L'import échoue à l'étape cwb-makeall en cas de "présence d'absence de valeurs propriétés" (retour détaillé fait à MD par mail) 
 +    * **MD corrigé** l'étape de tokenisation n'était pas faite 
 +    * **AL correction confirmée TXM 0.8.0.201904161055** 
 +  * Après l'erreur cwb-makeall le corpus s'affiche tout de même dans la liste, et il n'y a pas de moyen de savoir s'il est fonctionnel ou non (0.7.9 affichait "corpus not ready" dans ce cas) 
 +    * **MD corrigé** après un échec d'import les corpus ne devraient pas s'afficher
-préférence de 2 modes de recalcul des résultat enfants : "automatique" et "manuel"+SJ 2019-02-19
-commande manuel "Recalculer les résultats"+  * la fonction "Deviner" la langue ne fonctionne plus :<code>Error: no C:\Users\s\TXM_0.8.0_dev\treetagger-models\??.par model file found for the ?? lang. 
 +Error while importing corpus during 'annotate' step, reason=TreeTagger annotation failed. 
 +End of Groovy import script: 573 msec (573 ms) 
 +Erreur: l'import ne s'est pas terminé correctement. Voir les messages précédent. 
 +</code> 
 +    * **MD corrigé** [[http://forge.cbp.ens-lyon.fr/redmine/issues/2511|ticket #2511]]
-Problématiques de chaque mode : +FR 2019-03-20
-  * automatique +
-    * les résultats sont maj sans que l'utilisateur vérifie les données utilisée (il faut le faire après coup) +
-    * maîtriser les temps de calcul +
-    * difficultés pour mesurer l'impacte sur les résultats frères +
-  * manuel +
-    * problème de cohérence pour la persistence des résultats +
-    * problème de cohérence pour le cas de 2 AFC calculées sur un état différent d'une LT+
-Question subsidiaire : que faire des résultats sauvés après une maj de corpus ? -> problématique de validation des données+  * échec de l'import du corpus Hobbes8.1 dans TXM 0.8.0beta4 Windows : <code>ApplyXsl2 with the C:\Users\Utente\TXM-0.8.0\hobbes-v8.1-li-noi-src\xsl\2-front\convert-pb-facs-eebo-id-to-filename.xsl stylesheet. 
 +Debug mode enabled. 
 +-- Applying C:\Users\Utente\TXM-0.8.0\hobbes-v8.1-li-noi-src\xsl\2-front\convert-pb-facs-eebo-id-to-filename.xsl XSL to 3 files with parameters: {output-directory=file:/C:/Users/Utente/TXM-0.8.0/corpora/HOBBESV81LINOISRC/src/} on directory C:\Users\Utente\TXM-0.8.0\corpora\HOBBESV81LINOISRC\txm\HOBBESV81LINOISRC result written in C:\Users\Utente\TXM-0.8.0\corpora\HOBBESV81LINOISRC\txm\HOBBESV81LINOISRC 
 +003 .copying inputfile to: C:\Users\Utente\TXM-0.8.0\corpora\HOBBESV81LINOISRC\txm\HOBBESV81LINOISRC\tmp\01elements.xml 
 +Error  
 +  I/O error reported by XML parser processing 
 +  file:/C:/Users/Utente/TXM-0.8.0/corpora/HOBBESV81LINOISRC/txm/HOBBESV81LINOISRC/01elements.xml: Byte non valido 2 della sequenza UTF-8 a 3 byte. 
 +net.sf.saxon.trans.XPathException: I/O error reported by XML parser processing file:/C:/Users/Utente/TXM-0.8.0/corpora/HOBBESV81LINOISRC/txm/HOBBESV81LINOISRC/01elements.xml: Byte non valido 2 della sequenza UTF-8 a 3 byte.</code> 
 +    * **MD corrigé**
-**Paramètres déportés**+SLH 2019-03-24 (Ubuntu 18.04) 
 +  * l'import XML-TEI Zero+CSV ne lit pas les paramètres d'import dans le fichier import.xml de sources 0.7.9 : il faut qu'il le fasse. Il faut au minimum aider à décoder les valeurs de paramètres. 
 +    * **MD corrigé** 
 +    * **AL correction confirmée TXM 0.8.0.201904161055**
-solution : +AL 2019-04-03 (Ubuntu 16.04, TXM 0.8.0.201903221605) 
-  * A) oui ou non ? +  * les éditions supplémentaires créées par des scripts XSLT ne sont pas accessibles à la fin de l'import (il faut patcher à la main les fichiers de préférences
-  * B) préférences afficher les paramètres déportés : "oui" / &quot;non&quot;+  * si on remplace un ancien corpus par un nouveau et que les noms des éditions changent, les anciennes préférences persistent 
 +  * impossible de définir les éditions par défaut sans patcher le fichier de préférences du projet 
 + * **MD en cours** [[http://forge.cbp.ens-lyon.fr/redmine/issues/2564]] 
 +  * **AL correction confirmée TXM 0.8.0.201904161055**, mais un petit problème tout de même :  
 +    * si les éditions XSL ne remplacent pas default et qu'elle est produite en mode groovy, l'édition existe, mais n'est pas déclarée 
 +AL 2019-04-04 (Ubuntu 16.04, TXM 0.8.0.201903221605) 
 +  * l'étape XSLT "1-split-merge" ne fonctionne pas, message d'erreur : 
 +<code> 
 +Démarrage du script d'import Groovy xtzLoader.groovy. 
 +-- Split-Merge XSL Step with /home/alavrent/xml/davydovachron-fr-txm080/xsl/1-split-merge 
 +groovy.lang.MissingMethodException: No signature of method: static org.txm.importer.ApplyXsl2.processImportSources() is applicable for argument types: (File, [Ljava.io.File;, HashMap, Boolean) values: [/home/alavrent/xml/davydovachron-fr-txm080/xsl/1-split-merge/txm-merge-and-split-davydova.xsl, ...] 
 +Possible solutions: processImportSources(java.io.File, [Ljava.io.File;, java.util.HashMap), processImportSources(java.io.File, java.io.File, java.io.File, java.util.HashMap, boolean), processImportSources(java.io.File, java.io.File, java.io.File), processImportSources(java.io.File, java.io.File, java.io.File, java.util.HashMap) 
 + at groovy.lang.MetaClassImpl.invokeStaticMissingMethod(MetaClassImpl.java:1528) 
 + at groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:1514) 
 + at org.codehaus.groovy.runtime.callsite.StaticMetaClassSite.call(StaticMetaClassSite.java:52) 
 + at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47) 
 + at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116) 
 + at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:152) 
 + at org.txm.scripts.importer.xtz.XTZImporter.doSplitMergeXSLStep(XTZImporter.groovy:188) 
 +... 
 + at org.txm.rcp.handlers.scripts.ExecuteImportScript$2.run(ExecuteImportScript.java:146) 
 + at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56) 
 +&lt;/code&gt; 
 +  * corpus de test pour reproduire le bug : %%webdavs://sharedocs.huma-num.fr/dav.php/@Shares/(948) Cactus/(3788) Cactus/Projets/JournauxFrancophones/Corpus/sources/davydovachron-fr-txm080.zip%% 
 +  * avec TXM 0.7.9 l'étape split-merge se déroule sans erreur sur ce corpus, modulo le bug connu de persistance de fichiers output standard ([[http://forge.cbp.ens-lyon.fr/redmine/issues/2284]]) 
 +    * **MD corrigé** 
 +    * **AL correction confirmée TXM 0.8.0.201904161055**
-si oui -> certains résultats+==== XML-TRS + CSV ====
-si non -> lorsque l'on créé une AFC, afficher une LT et AFC vides dans la vue corpus et ouvrir l'éditeur de la LT pour la configurer+FB 2019-03-06
-Problématiques de chaque mode +  * impossible d'importer un corpus en trs. Soit il se passe rien soit : <code> 
-  * oui +Démarrage du script d'import Groovy transcriberLoader.groovy. 
-    * pas de validation de la modification du parent +org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: 
-  * non +file:/home/flora/TXM-0.8.0/scripts/groovy/user/org/txm/scripts/importer/transcriber/compiler.groovy: 134: The current scope already contains a variable of the name project 
-    * ouverture d'une LT alors qu'une AFC a été demandée+</code> 
 +    * **MD corrigé**
-scénarios : +==== ODT/DOC/RTF + CSV ====
-  * modifier la propriété LT depuis AFC/Spécifs +
-  * modifier fmin de LT depuis AFC/Spécifs +
-  * modifier vmax de LT depuis AFC/Spécifs +
-  * passer en illustratif un point de AFC depuis la spécifs +
-  * Supprimer/merger lignes/colonnes depuis AFC/Spécifs +
-  * Supprimer/merger parties de la partition depuis AFC/Spécifs+
-cas particuliers  des résultats modifiés manuellement : +BP 2019-04-02 (Ubuntu 16.04, TXM 0.8.0, 0.8.0.1928, 0.8.0.201903221605) 
-  * LT avec des lignes supprimées/mergées +  * dans le formulaire d'import, il y a une section pour régler le découpage en pages, son rôle n'est pas clair car le manuel utilisateur semble dire qu'on découpe plutôt selon les pages du traitement de texte.  
-  * concordance avec des lignes supprimées +  * les étiquettes frpos du modèle TT FR habituel ont été passées en minuscules. Par ailleurs, j'ai l'impression que les lemmes eux aussi ont été "minisculisés" car la requête suivante ne donne aucun résultat : <code>[frlemma = "[A-Z].+"]</code>alors que la requête 
-  * corpus mis à jour en sauvant les annotations de la concordance+<code>"[A-Z].+"</code> 
 +ramène notamment "Paris", "France", et la requête<code>[frpos = "nam"]</code>ramène plusieurs centaines de résultats. 
 +    * **MD corrigé**
-**Persistance des résultats**+==== Alceste ====
-Préférences 2 modes de persistance : "tout nouveau résultat" / "manuelle" -> MANUELLE PAR DÉFAUT +BP 2019-03-05 (Ubuntu 16.04, TXM 0.8.0.1826, 0.8.0.201902271548
- +  * L'import Alceste fonctionne, cependant la console ne donne pas de message indiquant que l'import est terminé, dans mon cas les dernières lignes affichées sont celles-ci : &lt;code>
-  * "tout nouveau résultat" +End of cwb-makeall logging process. 
-    * pas de commande conserver +-- EDITION - Building edition 
-    * pas de stylage +Paginating 714 texts 
-  * "manuel" +%%% .........|.........|.........|.........|.........|.........|.........|.........|.........|.........|
-    * commande conserver dans la vue corpus +
-    * marqué ce qui n'est pas conservé : italic par défaut (on limite ainsi les différences d'affichage entre les 2 modes) +
- +
-Les modifications manuel de résultat ne sont pas conservées (au démarrage, au recalcul du résultat) +
- +
-Scénarios : +
-  * Dans TXM 0.5, modifier la requête CQL créé une nouvelle concordance, à partir de TXM XX, la concordance est éditée sur place +
- +
-**Stylage des objets de la vue corpus** +
- +
-États : +
-  * persisté : rien par défaut +
-  * non-persisté : italique +
-  * éditeur ouvert&amp;premier plan : gras +
-  * non-rechargé : rien par défaut +
-  * dirty : étoile +
-     +
-voir la possibilité dans les préférences les stylages disponibles : rien / gras / italic / grisé / étoile / punaise / bullet +
- +
-====== ALPHA 3 ====== +
- +
-===== Installation ===== +
-  * BP (29/10/2018, TXM 0.8.0.1216) : tout semble bien se passer ; +
-    * sous le HOME je n'ai pas un répertoire TXM-0.8.0a3 mais un répertoire TXM-0.8.0 (qui a écrasé au moins en partie le répertoire du même nom précédent) (il me reste aussi un répertoire TXM-0.8.0a2). +
-    * pas de message d'erreur pour l'installation de R (comme j'avais eu en 0.8.0 alpha 2), et de fait j'ai pu calculer des cooccurrences. +
-  * AL (30/10/2018, TXM RCP 0.8.0.1216) +
-    * Ce serait bien de savoir comment désinstaller les alpha précédentes proprement (la Logithèque n'y arrive pas), j'ai donc 3 TXM en parallèle. +
- +
-===== Extensions ===== +
- +
-==== Tree Tagger ==== +
-  * BP (29/10/2018, TXM 0.8.0.1216) : +
-    * sans avoir rien installé, je lance un import (Alceste) : l'import semble bien fonctionner (cf. retours ci-après sur l'import Alceste), mais avec un warning comme quoi le modèle de langue TT manquait. +
-    * j'installe l'extension d'installation des modèles de langue EN et FR. Puis proposition de redémarrage que je valide. +
-    * je supprime le corpus précédemment créé, je relance l'import : cette fois l'import bloque dès le départ en indiquant qu'il n'y a pas Treetagger. +
-    * j'installe l'extension d'installation de Tree Tagger. Puis proposition de redémarrage que je valide. +
-    * je retente l'import de mon corpus, j'obtiens les messages suivants :<code> +
-Démarrage de TXM 0.8.0.1216... +
-Terminé. +
-.Prêt. +
-Updating TreeTagger binaries path...Done. +
-Updating TreeTagger models path...Done. +
-Using parameters from already imported corpus: null +
-Sauvegarde des paramètres d'importation... +
- +
-Error: path to TreeTagger is wrong: /home/bpincemi/plugins/org.txm.treetagger.core.linux_1.0.0.201810191105/res/linux/bin +
-Error: TreeTagger annotation engine is not ready please check TXM > Advance > TAL > TreeTagger preferences. Aborting +
-Terminé. +
-TXMResult.compute(): Project: computing failed.+
</code> </code>
-    * Je vais voir les préférences, les chemins indiqués sont les suivants :<code> +    * **MD corrigé**
-Chemin du dossier d'installation : /home/bpincemi/plugins/org.txm.treetagger.core.linux_1.0.0.201810191105/res/linux +
-Chemin du dossier de modèles linguistiques : /home/bpincemi/plugins/org.txm.treetagger.core.models_1.0.0.201810191105/res/models +
-</code> or effectivement je n'ai pas de répertoire plugins sous home/bpincemi. +
-    * MD **OK** le chemin était mal réglé et les fichiers modèles n'étaient pas exporté dans le plugin +
-  * BP (05/11/2018, TXM 0.8.0.1216) : pour pouvoir poursuivre la dernière fois, j'avais changé les chemins dans le réglage des préférences pour pointer vers le Treetagger que j'utilisais avec les versions précédentes. Mais quand je redémarre TXM quelques jours après, ces réglages ont été perdus et au relancement de mon import (car mon corpus a disparu) je retrouve un message analogue à celui ci-dessus. Je quitte TXM pour essayer de voir si je ne me suis pas trompée de programme et si je retrouve mon TXM 0.8.0a3 ailleurs. J'essaye le TXM 0.8.0 qui semble bien être l'alpha de juin. Je relance donc TXM 0.8.0a3, et l'import Alceste, et cette fois-ci j'obtiens des messages encore différents :<code> +
-Warning: image not found in 'org.txm.rcp' -> 'icons/logo/TXM logo.png' +
-Warning: image not found in 'org.txm.rcp' -> 'icons/logo/TXM logo 64x64.png' +
-Démarrage de TXM 0.8.0.1216... +
-Création de l'espace de travail utilisateur de TXM. +
-Terminé. +
-.Prêt. +
-Installing sample corpus... +
-VOEUX.txm binary corpus is not a TXM 0.8.0 corpus (no .settings nor .project file) +
-graal.txm binary corpus is not a TXM 0.8.0 corpus (no .settings nor .project file) +
-Terminé. +
-2 corpus loaded. +
-TXM est prêt. +
-Updating TreeTagger binaries path...Done. +
-Updating TreeTagger models path...Done. +
-New import corpus project. +
-Sauvegarde des paramètres d'importation...+
-org.eclipse.core.internal.resources.ResourceException: Problems encountered while moving resources+BP 2019-04-12 (Ubuntu 16.04, TXM 0.8.0.2009, 0.8.0.201904121205) 
- at org.eclipse.core.internal.resources.Resource.move(Resource.java:1514) +  * Je ne sais pas si c'est spécifique à l'import Alceste, mais après j'ai constaté qu'après un tel import la commande Propriétés ne semble pas trouver le fichier de description HTML associé au corpus : 
- at org.eclipse.core.internal.resources.Resource.move(Resource.java:1475) +<code> 
- at org.txm.objects.Project._compute(Project.java:282) +Information HTML file doesn't exist
- at org.txm.core.results.TXMResult.compute(TXMResult.java:1925) +Stacktrace:  
- at org.txm.core.results.TXMResult.compute(TXMResult.java:1844) +[1]    org.txm.properties.rcp.editors.PropertiesEditor.updateEditorFromResult  PropertiesEditor.java, 157 
- at org.txm.rcp.handlers.scripts.ExecuteImportScript$2.run(ExecuteImportScript.java:162) +[2]                      org.txm.rcp.editors.TXMEditor.               refresh  TXMEditor.java, 1061 
- at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56) +[3]                      org.txm.rcp.editors.TXMEditor.           openEditor  TXMEditor.java, 1016 
-Contains: Resource already exists on disk: '/home/bpincemi/TXM-0.8.0/corpora/ELYSEE181105'. +[4]                      org.txm.rcp.editors.TXMEditor.           openEditor  TXMEditor.java, 983 
-TXMResult.compute(): Exception occurs during computing: org.eclipse.core.internal.resources.ResourceException: Problems encountered while moving resources. +[5]  org.txm.properties.rcp.handlers.ComputeProperties.              execute  ComputeProperties.java, 82 
-Terminé.+[6]                            org.txm.rcp.Application.                start  Application.java, 242
</code> </code>
-    * MD, il s'agit d'un autre bug, à creuser +  * Suite : Après avoir redémarré, la commande Propriétés semble fonctionner normalement (sur le corpus et sur la partition que j'avais créée, alors qu'elle ne fonctionnait ni sur l'un ni sur l'autre). En revanche, une partition que j'ai créée dans la session du premier lancement a un comportement anormal : les fréquences de l'index de partition sont anormalement basses, mais moins basses dans la dernière partie. Pourtant les tailles des parties semblent bonnes. Après un redémarrage, j'ai recréé la même partition, et cette fois-ci l'index de partition se comporte normalement.
-      * MD **OK** ça devrait aller mieux+
-==== Word Cloud ==== +===== Annotation =====
-  * BP (05/11/2018, TXM 0.8.0.1216) : +
-    * <del>installation OK ; lancement depuis un index OK.</del> +
-    * <del>les commandes de la barre des paramètres de rendu semblent indisponibles : soit on n'a pas de modification, soit on semble avoir un recalcul du nuage (autre positionnement des mots) mais sans changement du paramètre de rendu sollicité.</del> [SJ: j'ai désactivé la barre de rendu pour le WordCloud. Plus tard on pourrait augmenter RWorkspace pour changer la font, mode de rendu, etc.]+
-===== Import =====+FB 2019-03-06
-==== Alceste ==== +  * sous Linux, plus de préférences (onglet vide) dans TXM > Utilisateurs > Annotation 
-  * BP (29/10/2018, TXM 0.8.0.1216) : +    * SLH : la rubrique "TXM > Utilisateurs > Annotation" est même doublée (et vide) 
-    * l'import Alceste aboutit : je n'ai pas de message disant que l'import est fini mais je récupère un corpus sur lequel je peux appliquer des commandes : description, concordance, édition. Voici le contenu de la console (j'ai tronqué les lignes de points) :<code> +      * **MD corrigé** 
-Sauvegarde des paramètres d'importation...+  * l'annotation ne fonctionne que sur les propriétés déjà présentes, on ne peut pas en recréer ? ou import différent ?? 
 +    * SLH : on peut ajouter de nouvelles propriétés de mots à annoter, [[https://sourceforge.net/p/txm/code/HEAD/tree/trunk/doc/user%20manuals/txm-manual-fr.odt?format=raw|consulter le fichier ODT courant du manuel 0.8 en cours de rédaction]] (voir la section 12.3 Annotation de propriétés de mots par concordances page 183
 +  * l'annulation de l'enregistrement d'une annotation provoque la suppression du corpus 
 +    * **MD corrigé**
--- IMPORTER - Reading source files +FB - 2019-03-08 
-Some attributes were duplicated: [id2] +   * l'annotation est possible pour tous types de corpus mais ne peut s'enregistrer que sur un XML-"XTZ" (**MD** oui, seul l'import XTZ permet de mettre à jour le corpus). L'enregistrement est assez long, ça peut faire peur.  
-707 texts found in /home/bpincemi/area/data/2018/projet/textometrie/3corpus/politique/elysee/181029src/elysee/export.txt +     * **MD** la sauvegarde de l'annotation rejoue les étapes compiler et pager de l'import XTZ 
-Tokenizing files (707) +   * Mettre une information comme quoi l'enregistrement est terminé et à fonctionné
-.............................. +     * **MD corrigé** 
-Tagging sentences of 707 files +   * Peut-on avoir l'annotation sur plusieurs mots mais tout en gardant l'idée d'une seule annotation pour un groupe de mots ? 
-.............................. +     * **MD** oui avec l'un des 2 modes d'annotation des structures
-Building xml-tei-txm (707 files) +
-.............................. +
--- ANNOTATE - Running NLP tools +
-Error: No Modelfile available for lang /usr/lib/treetagger/models/FR.par. Continue import process  +
--- COMPILING - Building Search Engine indexes +
-process 707 files +
-.............................. +
-[p:[n], s:[n], lb:[n], txmcorpus:[lang], text:[id, titre, president, id2, quand, qui, annee, base, project]] +
-pAttrs : [id, lbn, pn, sn, n] +
-sAttrs : [p:+n, s:+n, lb:+n, txmcorpus:+lang, text:+id+titre+president+id2+quand+qui+annee+base+project] +
--- EDITION - Building edition +
-Paginating texts:  +
-.............................Terminé. +
-</code> +
-En fait on ne voit pas le "Terminé" si la ligne de points est longue. +
-    * cependant l'annotation par TreeTagger ne fonctionne pas car 'd'après la console) le modèle de langue cherché est "FR.par", or dans l'aide à l'installation de TreeTagger on demandait de nommer ce modèle "fr.par".<code>Error: No Modelfile available for lang /usr/lib/treetagger/models/FR.par. Continue import process </code> +
-    * par ailleurs le contenu par défaut de la description de l'import est "The source directory contains the sources files." au lieu du nom de l'utilisateur, de la date, etc. comme dans d'autres imports ; et une fois l'import effectué, dans la description du corpus, on a la mention initiale "Build the alceste import module" (comme si le contenu du champ n'avait pas été utilisé de toutes façons ?) -> cela gagnerait à être ajusté à l'occasion+
-    * la tokenisation ne semble pas utiliser les caractères d'élision ? : dans le paramètre d'import, j'ai l'apostrophe simple "'" qui est déclarée comme caractère d'élision, dans mes sources si je cherche ce caractère qui est dans les paramètres d'import, il correspond bien aux apostrophes du texte initial ; mais dans mon corpus TXM si je cherche .+'.+ je n'ai aucun résultat, alors que si je cherche .+'.+ je trouve "c'est", "qu'il", "j'ai", "l'Europe", "aujourd'hui", "l'ensemble" etc.+
-==== XTZ + CSV ==== 
-  * AL (2018-10-30, TXM 0.8.0.201810191541) 
-    * Pour les répertoires de sources créés sous TXM 0.7.9 et avant, certains paramètres stockés dans import.xml ne sont pas reconnus (e.g. les plans textuels) 
-    * La langue par défaut pour l'annotation TreeTagger est "FR" or nous avons toujours recommandé de nommer les modèles avec des minuscules. En revanche, la liste déroulante propose les noms de fichiers modèles disponibles 
-    * Lors de l'import la console ne défile pas à l'écran, il faut scroller manuellement pour suivre l'évolution 
-    * L'étape d'annotation par le TreeTagger n'est pas affichée dans la console (en mode Severe et Warning, en tout cas) 
-    * La durée de l'import n'est pas affichée, c'était très pratique pour les tests de l'import 
-    * Les éditions XSL multiples sont créées mais restent indisponibles (problème du nouveau système de préférences ?) 
-    * Pour certains corpus la création d'édition par défaut échoue <code> 
--- Building 'default' edition of  1 texts... 
- .Fail to build 'default' edition for text: /home/alavrent/TXM-0.8.0/corpora/QJOYESKA/txm/QJOYESKA/QJoyesKa.xml 
-</code> 
-    * en revanche, si une édition "default" XSL est construite correctement 
-    * dans le corpus binaire, fichier .settings/TextualPlans.prefs, l'usage de camelCase est incorrect : 
-      * MileStones -> Milestones (1 seul mot en anglais) 
-      * OutSide -> Outside 
-      * NB: dans la tei, il n'y a jamais de majuscule à la 1ère lettre. Pourquoi pas faire pareil? 
-         
-  * GL (2018-12-11, TXM 0.8.0.2018  10191541?) 
-    * Je conseillerais d'ajouter des valeurs de défaut pour les différents paramètres d'import (ou du moins d'ajouter des commentaires), ex : 
-      <code> 
-      Outside-text-to-edit: TEIheader 
-      Milestones elements: <pb/></code> 
-    * Si on tente un import avec un répertoire qui contient déjà un import.xml, en modifiant certains paramètres, par exemple le nom, il me semble que l'import échoue. Exemple de message obtenu : 
-       <code> 
-        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56) 
-        Error: import not correctly ended. See console messages. 
-        Done. 
-        TXMResult.compute(): Project: computing failed.</code> 
-    * (on aimerait bien savoir où se trouvent les 'console messages' !) 
-    * En faisant un nouveau test, après avoir éliminé le fichier import.xml, l'import se termine normalement. 
-  
-===== Vue Corpus =====+==== Annotation de propriétés de mots ====
-  * AL (2018-10-30, TXM 0.8.0.201810191541) +FB - 2019-02-18 
-    * <del>Double-clic sur l'icone fonctionne pour Index et concordance, mais pas pour Lexique</del> [SJ: fixé par MD] +   * Suite au changement d'une propriété de mot et à son enregistrement, le corpus a ainsi été rechargé mais il n'y a plus les sous corpus et partition créés 
-    * <del>Export des données n'est plus disponible pour les corpus, sous-corpus et partitions : OK !</del> +     * **MD corrigé** 
-    * <del>Renommage de corpus fonctionne et persiste : OK !</del> +FB - 2019-03-06 
-    * Au bout d'un certain nombre de manipulations (import, chargement de corpus, renommage, redémarrage), certains corpus sont dupliqués dans la vue corpus {{:public:retours_de_bugs_logiciel:vuecorpus.jpg|corpus dupliqués}}+   * la macro buildwordproptable ne fonctionne plus 
 +     * **SJ: reporté, voir ticket [[http://forge.cbp.ens-lyon.fr/redmine/issues/2523]]**
-  * BP (05/11/2018, TXM 0.8.0.1216+BP 2019-03-19 (Ubuntu 16.04, TXM 0.8.0 beta 4, 0.8.0.1913, 0.8.0.201903181603
-    * Le corpus que j'ai importé la fois précédente (cf. retours sur l'import -import Alceste) a disparu au redémarrage de TXM+  * Je me mets dans le cas de figure où je souhaite corriger des erreurs d'étiquetage TreeTagger dans le corpus VOEUX. Je construis une concordance de "des", je vois que toutes les occurrences ont frpos="PRP:det" et frlemma="du". Or dans un certain nombre de cas, où la construction est directe (sans préposition, passer au singulier par exemple pour s'en apercevoir), il faudrait frpos="DET:ART" et frlemma="un". Je souhaite donc effectuer cette correction pour une ou plusieurs lignes sélectionnées. 
-    * Après des opérations d'annotation, je redémarre TXM, et j'ai 6 fois le corpus GRAAL et 6 fois le corpus VOEUX. Le corpus sur lequel avait porté mes annotations n'est pas dupliqué.+    * je n'arrive pas à modifier en même temps la correction sur les deux propriétés (j'ai essayé par exemple en cliquant sur le dernier bouton "OK"). Du coup c'est particulièrement lourd pour faire cette double modification car la sélection faite pour la première modification est perdue dès que celle-ci est appliquée, il faut donc retrouver et re-sélectionner les lignes à modifier pour appliquer la 2e correction
 +    * ayant corrigé l'annotation sur une occurrence, je sauve l'annotation, et j'ai dans la console des messages qui semblent confirmer que tout s'est bien passé : 
 +<code> 
 +Concordance de <"des|un"> dans le corpus VOEUX... 
 +1069 occurrence(s). 
 +Affectation de la valeur DET:ART à la propriété frpos pour 1 occurrences. 
 +Affectation de la valeur un à la propriété frlemma pour 1 occurrences. 
 +Enregistrement de 2 annotations... 
 +Annotations enregistrées. 
 +</code> 
 +    * pourtant, si je re-calcule à nouveau la concordance pour voir si mon annotation a bien changé, je ne retrouve pas ma modification, les valeurs de frlemma et frpos sont toujours les anciennes. 
 +    * faut-il revoir le code ? les messages dans la console ? ou la documentation ? 
 +    * **MD corrigé** la sauvegarde ne se faisait pas 
 +    * **MD pour plus tard :** revoir le scénario multi propriétés [[http://forge.cbp.ens-lyon.fr/redmine/issues/2533|#2533]]
-===== Menu Corpus ===== +AL 2019-04-03 (Ubuntu 16.04, TXM 0.8.0.201903221605) 
-==== Propriétés de corpus ==== +  * la sauvegarde des annotations peut prendre plusieurs minutes (par exemple s'il faut re-générer des éditions XSLT ou si le corpus est volumineux). Or l'objet corpus reste actif pendant le réimport, on peut appeler des commandes pendant ce temps, ce qui provoque des erreurs. Le réimport se poursuit normalement toutefois. 
-  * AL (2018-10-30, TXM 0.8.0.201810191541+    * **MD en partie corrigé** la fenêtre du job de re-import s'affiche devant l'UI par défaut, ce qui gêne le lancement d'autres commandes (voir ticket) 
-    * Modification du nom de corpus dans l'onglet de propriété fonctionne, mais ne persiste pas (modifications perdues si on ferme TXM). La mise à jour de la partie basse ne se fait que si on appuie d'abord sur le 1er, puis sur le 2e bouton Apply +  * le dernier message de la console après réimport est "-- Fetching page word IDs... \\ 001 .". Il faudrait afficher un message plus explicite annonçant la fin de l'opération. 
-      * MD **OK**+    * **MD corrigé**
-==== Vue interne ==== +===== Extensions =====
-  * AL (2018-10-30, TXM 0.8.0.201810191541) +
-    * <del>Impossible d'avancer dans l'affichage : les bouton "Suivant", "Dernier" ou saisie directe ne fonctionnent pas</del> [SJ: fixé]+
-==== Sous-corpus ==== +SLH 2019-03-24 (Ubuntu 18.04
-  * AL (2018-10-30, TXM 0.8.0.201810191541+  * l'ajout des extension TreeTagger Software et TreeTagger models provoque les messages suivants dans la console, qu'il faut retirer :<code> 
-    * Mode assisté : des requêtes sont générées à partir des métadonnées disponibles, mais les caractères spéciaux éventuels ne sont pas échappés, du coup la création de sous corpus peut échouer. E.g. pour l'auteur "Adgar (dit Guillaume)" de la BFM, la requête générée est <code>/region[text,a]:: a.text_auteur="Adgar (dit Guillaume)"</code> au lieu de <code>/region[text,a]:: a.text_auteur="Adgar \(dit Guillaume\)"</code> +!ENTRY org.eclipse.equinox.p2.discovery 4 0 2019-03-23 17:26:16.754 
-    * Dans l'interface, j'aurais remplacé "certains critères" par "au moins un critère" et j'harmoniserais Maj ou min pour les deux options+!MESSAGE Unknown category 'null' referenced by connector 'org.txm.treetagger.binaries.feature.feature.group' declared in http://textometrie.ens-lyon.fr/dist/0.8.0/ext/stable
-==== Partition ==== +!ENTRY org.eclipse.equinox.p2.discovery 4 0 2019-03-23 17:26:16.758 
-  * AL (2018-10-30, TXM 0.8.0.201810191541) +!MESSAGE Unknown category 'null' referenced by connector 'org.txm.treetagger.models.feature.feature.group' declared in http://textometrie.ens-lyon.fr/dist/0.8.0/ext/stable
-      * <del>Pas d'anomalie détectée (testé partition en mode assisté pour le corpus BFM2016)</del> +
- +
-==== Table lexicale === +!ENTRY org.eclipse.equinox.p2.discovery 4 0 2019-03-23 17:26:16.758 
-  * AL (2018-10-30, TXM 0.8.0.201810191541) +!MESSAGE Unknown category 'null' referenced by connector 'org.txm.wordcloud.feature.feature.group' declared in http://textometrie.ens-lyon.fr/dist/0.8.0/ext/stable
-    * <del>Pas d'anomalie détectée</del>+
-  * SJ (2018-11-23+!ENTRY org.eclipse.equinox.p2.discovery 4 0 2019-03-23 17:26:16.763 
-    * plantage si l'index n'a qu'une seule ligne de résultat et que l'on choisit "Total toutes les occurrences recenses par l'index"+!MESSAGE Unknown category 'null' referenced by connector 'org.txm.tigersearch.feature.feature.group' declared in http://textometrie.ens-lyon.fr/dist/0.8.0/ext/stable
-      * faire un index de partition sur VOEUX et "lui", créer une table lexicale avec l'option "Total toutes les occurrences recenses par l'index" => plantage R +
-      *  Au passage je trouve les textes des 2 options pas très explicites +
-    * premier problème de compute en cascade => que faire des résultats enfant d'un index de partition lorsque la requête est changée ? +
-    * changer la propriété d'une table lexicale créée depuis un index sur partition ne fait rien. La table est toujours recréée depuis l'Index parent. Modifier l'Index modifie la table  => à discuter, quel doit être le comportement ? +
-    * discuter des liens entre ces 2 types de résultats. Problème notamment de l'index qui peut avoir 2 propriétés alors que la table lexicale non. +
-      * proposition: si parent = index de partition => alors masquer les paramètres déportés +
-  - <del>supprimer la commande "Table lexicale" sur Index qui ne vient pas d'une partition au lieu de proposer la dialog box qui va inexorablement pointer vers une erreur</del> [SJ: OK]+
-===== Menu Outils ===== +!ENTRY org.eclipse.equinox.p2.discovery 4 0 2019-03-23 17:26:16.763 
-  * AL (2018-10-30, TXM 0.8.0.201810191541) +!MESSAGE Unknown category 'null' referenced by connector 'org.txm.backtomedia.feature.feature.group' declared in http://textometrie.ens-lyon.fr/dist/0.8.0/ext/stable
-    * <del>Fonctionnalités testées : Lexique, Index, Concordance, Progression, Références, Spécificités, AFC. Seuls les bugs sont signalés</del>+
-==== Concordance ==== +!ENTRY org.eclipse.equinox.p2.discovery 4 0 2019-03-23 17:26:16.767 
-  * AL (2018-10-30, TXM 0.8.0.201810191541) +!MESSAGE Unknown category 'null' referenced by connector 'org.txm.annotation.urs.feature.feature.group' declared in http://textometrie.ens-lyon.fr/dist/0.8.0/ext/stable 
-    * <del>Il y a apparemment une erreur dans le calcul du total des occurrences. Le total affiché est égal au nombre d'occ - 1; e.g. "1-59 / 58"</del> [MD **OK** fixed] +</code> 
-  * BP (05/11/2018, TXM 0.8.0.1216) +    * **MD corrigé**
-    * <del>Si je modifie la propriété d'affichage du pivot cela modifie aussi, et de la même manière, la propriété de tri du pivot. Je n'arrive pas à dissocier les deux, à mettre une autre propriété de tri.</del> [MD **OK** fixed]+
-==== Progression ==== +===== Macros =====
-  * AL (2018-10-30, TXM 0.8.0.201810191541) +
-    * <del>Ajout/suppression dynamique de requêtes OK</del> +
-    * <del>Mais si on clique sur le graphique, on ne peut plus taper dans le champ de la requête, il faut passer par l'assistant de requête pour réactiver la saisie</del> +
-      * <del>SJ: non reproductible sous Windows</del> +
-        * <del>MD: je confirme le bug, le focus à l'air d'être sur le champ requete (ou spinner, etc.) mais les événements de clavier ne sont pas transmis</del> +
-          * <del>MD: **OK** on a desactiver l'electrique sur les widget de type Spinner car la gestion des événements est trop différente entre les OS</del> [SJ: fixé: changement de listener sur les Spinner => ModifyTextListener au lieu d'un SelectionListener]+
-==== Spécificités ==== +==== BasicVocabulary ====
-  * AL (2018-10-30, TXM 0.8.0.201810191541) +
-    * l'étiquette de "banalité" semble dupliquée avec un léger décalage {{:public:retours_de_bugs_logiciel:banalite.jpg|copie d'écran}} +
-      * MD: fixed ? +
-        * SJ: faudrait faire des tests plus poussé sous Linux, je ferai un ticket un peu plus tard+
-  * BP (2018-11-22, TXM 0.8.0.1216+BP 2019-04-04 (Ubuntu 16.04, TXM 0.8.0, 0.8.0.1928, 0.8.0.201903221605
-    * Ce n'est pas exactement la commande Spécificités, mais c'est peut-être un peu lié ? Je n'arrive pas à utiliser la macro PlotSpecif pour le calcul d'une spécificité à partir de ses quatre paramètres (y compris avec les valeurs par défaut), j'ai le message d'erreur suivant :<code> +  * La macro ne fonctionne plus, elle indique le message d'erreur suivant :<code> 
-NLS missing message: ExecuteScript_11 in: org.txm.rcp.messages.messages +** Erreur lors de l'exécution du script : groovy.lang.MissingMethodException: No signature of method: org.txm.specificities.core.functions.Specificities.getFrequency() is applicable for argument types: () values: [] 
-org/txm/macro/r/PlotSpecifMacro.groovy +Possible solutions: getFrequencies() 
-Error during script execution: groovy.lang.MissingMethodException: No signature of method: org.txm.statsengine.r.core.RWorkspace.plot() is applicable for argument types: (File, org.codehaus.groovy.runtime.GStringImpl) values: [/home/bpincemi/TXM-0.8.0/results/txm598229176872617115.svg, ...+Stacktrace:  
-Possible solutions: wait(), split(groovy.lang.Closure), dump(), grep(), find(), any() +[1]  org.txm.rcp.handlers.scripts.ExecuteGroovyScript$1.run  ExecuteGroovyScript.java, 270 
-groovy.lang.MissingMethodException: No signature of method: org.txm.statsengine.r.core.RWorkspace.plot() is applicable for argument types: (File, org.codehaus.groovy.runtime.GStringImpl) values: [/home/bpincemi/TXM-0.8.0/results/txm598229176872617115.svg, ...+groovy.lang.MissingMethodException: No signature of method: org.txm.specificities.core.functions.Specificities.getFrequency() is applicable for argument types: () values: [] 
-Possible solutions: wait(), split(groovy.lang.Closure), dump(), grep(), find(), any()+Possible solutions: getFrequencies()
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:72) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:72)
at org.codehaus.groovy.runtime.callsite.PojoMetaClassSite.call(PojoMetaClassSite.java:48) at org.codehaus.groovy.runtime.callsite.PojoMetaClassSite.call(PojoMetaClassSite.java:48)
- at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:136+ at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120
- at org.txm.macro.r.PlotSpecifMacro.run(PlotSpecifMacro.groovy:73)+ at org.txm.macro.stats.BasicVocabularyMacro.run(BasicVocabularyMacro.groovy:72)
at groovy.util.GroovyScriptEngine.run(GroovyScriptEngine.java:599) at groovy.util.GroovyScriptEngine.run(GroovyScriptEngine.java:599)
- at org.txm.rcp.handlers.scripts.ExecuteGroovyScript$1.run(ExecuteGroovyScript.java:244)+ at org.txm.rcp.handlers.scripts.ExecuteGroovyScript$1.run(ExecuteGroovyScript.java:259)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
</code> </code>
- +    * **MD corrigé**
-===== Annotation de propriétés de mots (Recette 3) ===== +
-  * AL (2018-10-30, TXM 0.8.0.201810191541) +
-    * Impossible de charger correctement le corpus VOEUX donné dans le lien de la recette (probablement, parce que le fichier est nommé "voeux-bin", cela provoque la création de deux répertoires binaires, le corpus n'est pas utilisable) +
-    * Si j'utilise le corpus VOEUX livré avec TXM, impossible d'enregistrer les modifications, car le corpus n'a pas été créé avec le module XTZ. Il faut reformuler la recette ! +
-    * Tentative d'annotation sur un corpus importé avec XTZ (ALEXISRAM) +
-      * requête [cattex-pos="ADJ.*"] [cattex-pos="NOM"] +
-      * pour les 6 premières occurrences, je remplace la valeur par "TEST" +
-      * j'enregistre la concordance +
-      * la requête [cattex-pos="TEST"] donne 12 résultats. L'étiquette a donc été modifiée pour les 2 mots du motif. Est-ce le comportement normal ? +
-      * erreur d'encodage de caractères dans la liste déroulante des types d'annotation ("?" au lieu de "é") +
-  * BP (05/11/2018, TXM 0.8.0.1216) +
-    * Je trouve intéressante la présentation unifiée de l'annotation dans la concordance (le même crayon donne accès à l'annotation sur les mots ou sur les séquences de mots). +
-    * Quand on fait une sélection multiple de lignes (controle + clic gauche), à chaque nouveau clic l'affichage se repositionne au début de la concordance. +
-    * Quand j'annote les mots, +
-      * j'ai édité le nom de la catégorie (dans l'idée d'ajouter une propriété que j'ai appelée "meteo"), mais quand j'ai appliqué mon annotation elle s'est enregistrée dans frlemma. Il me semblait qu'on pouvait ajouter de nouvelles propriétés (et pas simplement rectifier les valeurs de propriétés existantes), je me trompe ? +
-      * je suis toujours en difficulté pour corriger à la fois la POS et le lemme sur une sélection, car le bouton "OK" qui valide la correction porte sur une seule propriété, et après cette première validation la sélection est perdue pour pouvoir faire la seconde. (Mais je n'avais pas encore lu la recette qui indiquait de cliquer tout de suite sur le 2e OK.) +
-      * après avoir enregistré mes modifications (par deux corrections successives), quand je recherche les occurrences avec les valeurs de propriété que j'avais modifiées, seule la propriété frlemma semble avoir été modifiée (les modifications sur frpos semblent perdues), et cela seulement sur la première occurrence corrigée (et pas pour les 6 autres lignes que j'avais sélectionnées en même temps). +
-      * après avoir relu la recette, je recommence ma correction en cliquant cette fois-ci sur le OK de la 2e ligne (qui est dans mon cas frlemma). Je n'observe de modifications que sur les valeurs de frlemma, que ce soit dans l'affichage ou en recherchant les occurrences après sauvegarde des annotations. La modification de frlemma est bien prise en compte pour les 6 occurrences. +
-    * Quand j'annote des séquences de mots (qui ne sont pas dans la recette, donc c'est peut-être hors-sujet pour ces retours), +
-      * j'ai pu poser et interroger des annotations simples de type catégorie, ainsi que des annotations typées (catégorie/valeur) (au début je croyais que le 2e type ne fonctionnait pas car j'interrogeais sur <span_meteo="favorable">[]+</span> au lieu de <meteo_ref="favorable">[]+</meteo>) +
-      * je me demande si ce ne serait pas plus simple de ne proposer qu'un seul type d'annotation de séquences, qui soit typé ? (Mais il esttrès possible qu'il y ait des considérations qui m'échappent, il faudrait savoir pourquoi on propose ces deux types).+
public/retours_de_bugs_logiciel/txm_0.8.0.1545137770.txt.gz · Dernière modification: 2018/12/18 13:56 par sebastien.jacquot@univ-fcomte.fr