Stage de Jean-Noël Mayeur - IUT Schuman Illkirch - [3/09/18 au 8/06/18]

Important : cette page est réservée au suivi du stage, merci de ne pas la modifier

Informations générales pour les stagiaires

Pour toute information concernant ce stage : contacter Anaïs

Sujet

• Proposition de stage

Stage (Avril - Juin 2018)

Avril

• 9 :
  • Arrivée au CDS
  • Réunion de présentation des différents services et rôles de l'Observatoire
  • Installation de l'IDE Eclipse
  • Récupération du projet Git (problème avec le compte GitLab)
• 10 :
  • Résolution des problèmes pour la compilation du projet Eclipse (problème de librairies obsolètes)
  • Découverte du programme COSIM
• 11 :
  • Batterie de tests pour prendre en main COSIM et apprendre à configurer le fichier "parfile-tests"
  • Découverte l'outil d'analyse en Javascript pour visualiser les résultats de COSIM avec Aladin
  • Découverte des différentes fonctionnalités de la librairie JavaScript pour Aladin
• 12 :
  • Entretien avec Catherine Brunet pour pouvoir m'expliquer comment les documentalistes utilisent COSIM et des réels enjeux de celui-ci:
    • Explications des différentes options (OT, TRUST, COO, IGNORE, HIDE, SIGMA, ACRO, SEARC, EXEPT, OK)
    • Explications de différents termes techniques
    • Le fonctionnement de COSIM
    • Explication en détail du système de score
    • Présentation d'une partie de l'équipe des documentalistes travaillant avec COSIM
  • Recherche de solutions pour une possible intégration de code JavaScript (librairie Aladin) dans une interface Java
    • Solutions étudiées:
      • JavaFx
      • Librairie JxBroswer (Interface Swing), le problème étant qu'il s'agit d'une librairie payante

    • La solution la plus adaptée semble JavaFx (à rediscuter)

• 13 :
  • Séminaire sur la publication du deuxième catalogue (DR2) du satellite Européen Gaia
  • Prise en main de la librairie JavaScript pour Aladin
    • Mise en place d'un serveur HTTP grace a Python3
    • Réalisation du tutoriel de la librairie
    • Tentative d'ajout de différentes fonctionnalités (sans résultat réellement concluant à cause d'un problème de conversion des coordonnées des objets)
• 16 :
  • Résolution des problèmes lié a Git
  • Mise en place du dépot local Git
  • Résolution d'un problème sur Eclipse suite au changement du JDK
  • Rédaction du Wiki sur la première semaine

• 17 :

  • Révision des concepts de sérialisation en Java (interface Serializable et Externalizable)
  • Refléxion sur le mode de sérialisation à adopté entre les deux solutions :
    • Sérialisation binaire
    • Sérialisation XML
  • Le choix le plus pertinent semble le XML car :
    • Le fichier est directement déchiffable pour un humain (tout du moins bien plus compréhenssible qu'un fichier binary)
    • Contrairement aux fichiers binaires qui peuvent ne pas se générer sous la même forme selon la JVM utilisée, les fichiers XML sont toujours sous la même forme. Etant donné que le utilisateurs de COSIM n'ont possiblement pas tous la même JVM le choix le du XML assure que les fichiers de cache soient portatifs d'un utilisateur à l'autre
  • Test de XMLEncoder et XMLDecoder
• 18 :
  • Etude appronfondie du code (principalement de ParfileReader)
  • Tentative de résolution de l'échec de connexion a la base de données "simbad4a" (aucune solution trouvée)
  • Elaboration d'un diagramme UML pour mieux se rendre compte de la conception orienté objet du code
  • Quelques tests de serialisation (pour sérialiser des références sur d'autres objets)
• 19 :
  • Etude du code pour trouver des solutions de Serialisation
  • Tentative de résolution d'un bug lors de la connexion a la base de données (problème avec RMI)
• 20 :
  • Résolution du bug de connexion a la base de données, c'était un fait un fichier _Stub qui ne se générait pas lors de la compilation
  • Séminaire sur l'hydrogène et les galaxies
  • Première tentative d'implémenter directement la serialisation sur les objets astronomiques (quelques bugs restent non résolu)
• 23 :
  • Résolution des bugs de la serialisation mais il reste un problème : Les fichiers de cache sont beaucoup trop volumineux (de 11 à 12 Ko par objet)
  • Batterie de tests pour vérifier l'intégrité des données après le processus de sérialisation / désérialisation. Résultat, les données semblent être bien conservées
• 24 :
  • Changement de tactique pour sérialiser les objets : Les données sérialisées sont maintenant récupérée directement après la requête SQL (classe CResultSet) pour éviter au maximum les métadonnées inutiles
  • Tentative de résolution de nombreux bugs suite au changement de tactique de sérialisation
  • Les données sérialisées restent toujours trop volumineuses (7 à 8 Ko par objet), et la désérialisation ne fonctionne pas...
• 25 :
  • Changement de la structure du fichier de cache : Au lieu de sérialiser la classe directement on sérialise uniquement les informations vraiment utiles en les mettant dans des String (au lieu de les mettre dans des tableaux qui contiennent beaucoup de métadonnées)
  • La sérialisation et la désérialisation fonctionne enfin, chaque objet prends désormais 1700 a 1800 octets (sachant qu'il y encore quelques solutions simple pour réduire encore la taille des objets)
  • Test de la solution de serialisation / déserialisation sur le fichier de test fournit au début du stage, la comparaison des deux fichiers (fichier généré et fichier des résultats attendus) montre des résultats similaire sur certains points mais d'autres sont très différents
• 26 :
  • Découverte que d'autres CResults sont construits à partir de requêtes SQL.
  • Test de serialisation sur toutes les générations de CResults : A chaque construction d'un CResult le programme fait appel aux requêtes SQL pour récupérer les infos mais l'objet est directement sérialisé et deserialier pour vérifier que le processus se passe bien.
  • Tentative de mise en place d'un nouvel objet sérialisable qui contient toutes les informations (les CResults) nécessaire a la création d'un Astrobject
• 27 :
  • Séminaire sur l'analyse d'image astronomique automatique
  • Tentative de corrections des bugs liée à l'objet sérialisable censé regroupé toute les informations. Abandon temporaire de la solution
  • Tentative de supprimer toute les requêtes SQL pour utiliser uniquement les fichiers sérialisé (dans l'optique de faire des tests de performance pour comparer le temps d'éxecution entre la version avec requête et la version sans requête). Problème recontré lors de de la désérialisation alors que le processus de serialisation / déserialisation marche toujours très bien. Tentative de compréhension et de résolution du bug
• 30 :
  • Résolution d'un problème sur la connexion aux bases de données à cause d"Eclipse qui continuait d'utiliser le port 1100 (port de connexion a Simbad) même après la fin du Main. Le bug s'est reproduit plusieurs fois mais je n'ai pas réussi à isoler la cause...
  • Résolution des bugs de désérialisation. Un des principaux bug venait du fait que je ne serialisais pas un attribut des CResults étant donnée que je l'avais passer en static il y a une semaine de ça
  • La désérialisation sans aucune requête SQL pour les CRestult est donc opérationnelle

Mai

• 2 :
  • Changement de la structure de serialisation pour éviter d'avoir un fichier par CRessult comme ça l'était précédement
  • Ajout de la classe CandidatsSerialisation qui permet de regrouper tous les CResult d'un objet astronomique dans une seule classe
  • Ajout de la classe Cache qui contient une liste de tous les objets CandidatsSerialisation que nous devons sérialiser
  • C'est ensuite la classe Cache qui sera sérialisée, Au final on a donc toutes les informations nécéssaires dans un fichier Cache.bin ou Cache.xml (selon le choix)
  • La version binaire du Cache semble plus efficace car elle prend environ 100ms à se désérialiser et pèse 143Ko alors que la version XML prend aux alentours de 500ms à se désérialiser et pèse 1.34M
• 3 :
  • Réception du fichier de test contenant 3742 objets à tester pour comparer les performances entre la version basique de COSIM et la version qui utilise la sérialisation
  • Correction d'un petit bug bloquant lors de la déserialisation (suite à une tentative de connexion non voulue sur la base de données lorsque le catalogue n'était pas trouvé
  • Batterie de tests avec un nombre différents d'objets a tester a chaque fois pour voir l'évolution des performances selon le nombre d'objets sur les différentes versions du programme :
    • Version originale de COSIM
    • Version qui fait des requêtes SQL et qui les sérialise
    • Version qui ne fait pas de requête et qui lit le fichier Cache.bin
  • Conclusion des tests de performances :
    • La version qui fait les reqêtes SQL pour les sérialiser est entre 10 et 20% plus lente que la version originale puisqu'elle doit sérialiser toutes les données dans le fichier de cache (résultat prévisible)
    • La version qui utilise le fichier de cache est quand à elle environ 33% plus rapide puisqu'elle n'utilise pas la base de données de la BDD pour créer les objets
  • Optimisation possible :
    • Pour l'instant la seule idée pour réduire le temps de sérialisation serait de réduire le volume de données sérialisé, notament en ne sérialisant pas les données NULL par exemple. Cela permettrait aussi probablement de réduire le temps de désérialisation...
    • La version qui utilise le cache doit encore faire une requête pour récupérer une liste d'OID, il faudrait donc sérialiser cette liste également
• 4 :
  • Tentative d'optimisation de la mise en cache des données par la sérialisation des CResults, derniers bugs de cette optimisation presque résolue
  • Tentative de changement de l'approche de la sérialisation en sérialisant plutôt les objets construits à partir des CResults (les objets Candidats). Pour cela la remise aux normes JavaBeans du code lié à ses objets est nécéssaire même si la plupart implemente déjà l'interface Serializable (Mettre tout les accesseur get / set, les constructeurs par défault, ...), cette tache est assez laborieuse puisque beaucoup de classe sont concernée
• 7 :
  • Fin de la mise aux normes JavaBeans des classes
  • Corrections de quelques bugs lors de la sérialisation
  • Adapation de la classe Cache et de ParfileReader
  • Quelques tests de performances pour comparer les deux approches, ATTENTION : Le comparatif est basé sur des version non définitives des deux approches (quelques bugs et surtout des optimisations possible pour la première méthode (CResult) sont encore possible)
    • Tout d'abord il faut savoir que les résultats sont similaire à 99% mais quelques données (d'une importance très limité, cela ne change pas les résultats en profondeur). Le problème doit sans doute pouvoir ce régler assez facilement...
    • Le temps de taitement est un peu plus court avec la nouvelle méthode, mais sera peut-être plus long après l'optimisation de la première méthode (environ 20% plus rapide pour l'instant)
    • En raison de la très grande quantitée de classe a sérialisé le temps de sérialisation est très important, exemple :
      • Pour un test la version qui sérialise les CResults sérialise la cache en environ 2 secondes alors que la version qui sérilise les candidats ce temps monte à environ 15 secondes
    • La taille des cache est un peu plus importante avec la méthode qui sérialise les Candidats, on passe d'un fichier de 14Mo avec la méthode des CResults à un fichier de 20Mo avec la nouvelle méthode (les deux fichiers sont binaire)
• 9 :
  • Optimisation de la méthode de sérialisation avec CResults pour pouvoir comparer les performances finales des deux méthodes
  • Les deux méthodes offrent des performances similaires lors de la désérialisation, la seule différence se trouve donc dans la sérialisation ou elle est 2 à 3 fois plus longue avec la méthode qui sérialise les Candidats :
    • Pour la désérialisation :
      • La méthode des CResults est plus rapide à désérialiser le cache mais est plus longue lors du traitement puisqu'elle doit reconstruire tous les objets avec les CResults
      • La méthode des Candidats est plus longue à désérialiser le cache puisqu'elle doit construire tous les objets Candidats d'un coup mais est encuite plus rapide puisqu'elle n'a plus qu'à traiter les objets déjà construit
  • Tentative d'utilisation du cache sans initier la connexion, problème lors de la construction des Astrobject qui fait que le programme s'arrête dù a l'absence de connexion

• 11 :

  • Tentative d'isoler ce qui empêche la construction des Astrobject

  • Le problème survient lors de l'instanciation de plusieurs attributs de Astrobject

  • Tentative de sérialiser un object Astrobject vide pour pouvoir le réutiliser dans lors de la déserialisation au lieu de le réinstancier à chaque fois. Cependant le programme instancie plusieurs Astrobjects pendant l'exécution et cela implique donc de sérialiser autant d'Astrobjects qu'il y a d'instanciation (Les Astrobject sont "inutilisable" après leur utilisation c'est pour ça qu'ils sont réinstancier à chaque fois). Cette solution n'est donc pas adaptée du tout

• 14 :
  • Mise en place d'un fichier conf qui stocke les différentes options des fichiers utilisés. Il sert d'historique pour pouvoir garder les différentes configurations testées. Pour pouvoir savoir à quelles configurations il correspond il indique la date et l'heure à laquelle il a été crée
  • Début de la mise en place de l'interface JavaFx (version encore très basique)
  • Test de baisser la valeur de l'option SEARCH (qui définit le rayon de recherche) en utilisant le cache, un problème se pose :
    • Les objets qui se trouvent au-delà du rayon de recherche sont toujours pris en compte lors du calcul des scores puisque les candidats sont triés sur le rayon de recherche lors de la sérialisation. Quelles que soient les options du test les objets sont désérialisé et traité. Je travaille donc à filtrer ces objets indésirables lors de la déserialisation
• 15 :
  • Tentatives pour résoudre le problème qui survient lors du traitement des objets déserialiser après avoir baissé le rayon de recherche. Solution trouvée :
    • Juste avant que le score soit calculé pour chaque Candidat (dans la liste des Candidats) on vérifie que leur distance par rapport à la position souhaitée est inférieure ou égale. Si l'objet respecte cette condition il reste dans la liste mais si cette condition n'est pas remplie cela signifie qu'en temps normal (sans l'utilisation du cache) l'objet aurait été filtré et ne serait jamais arrivé dans la liste des Candidats potentiels. Il faut donc supprimer ce Candidat indésirable manuellement.
    • Un petit problème reste sans solution, Etant donnée que ce traitement est un peu différent du mode de filtre initial géré par la base de données certains objets sont filtrés (très minoritaires) alors que la version initiale l'aurait conservée. Cela est en fait dù à la précision des Double qui sont utilisés pour calculer la distance. Exemple : Un objet a une distance de 10 sera conservé sur la méthode initiale car la précision de ses calculs fait en sorte que sa distance soit strictement identique à 10.0, le calcul avec les Double quant à lui dira que l'objet se trouve à 10.0000000000123456, il est supérieur à 10 et sera donc rejeté... Cependant ce bug touche très peu de Candidats et n'est sans doute pas très important tant il est spécifique

  • Quelques tests pour vérifier que le fait de baisser la valeur de l'option .SEARCH (rayon de recherche) ne pose pas de problème. Mise à part le bug énoncé ci-dessus aucune donnée importante n'est perdue

• 16 :

  • Ajout des élements de base sur l'interface. Le slider, les boutons de validation ...

  • Ajout de la fonction pour pouvoir générer un nouveau fichier d'entrée qui prends en compte les nouvelles options (les ajoutes ou les modifies)
  • Début de la mise en relation entre l'interface et COSIM
• 17 :
  • Fin de la mise en relation entre l'interface et COSIM, pour l'instant seul l'option SEARCH est modifiable sur l'interface, les autres ne sont pas encore implémentés
  • Tentative de mise en place d'une fonctionnalité qui permettrait de garder le cache en mémoire entre les différents tests au lieu de désérialiser le fichier à chaque exéction de COSIM. Le problème de cette fonctionnalité c'est que si l'utilisateur baisse le rayon de recherche les objets qui seront supprimés du cache car ils ne sont pas dans le rayon de recherche ne seront plus présent si l'utilisateur réaugmente le rayon de recherche. Il faut donc résoudre ce problème

• 18 :

  • Mise en place des éléments d'interface qui permettent d'ajouter / modifier les options M (magnitude) et l'option V (vélocité)

  • Quelques tests sur ces nouvelles options en utilisant le cache lorsqu'on change ces options (je n'avais pas encore testé de changer ces options lors de l'utilisation du cache), les résultats sont bien ceux attendus
  • En fin de journée j'ai également réessayé d'ajouter la fonctionnalité qui permettrait de ne pas redésérialiser le cache à chaque validation
  • J'ai trouvé un problème lors de l'utilisation du cache avec l'interface :
    • Lorsque l'interface se lance le fichier n'a pas encore été désérialiser mais il serait intéressant de savoir dès le début le rayon maximal de recherche... Certaines solutions comme par exemple intégrer le rayon maximal dans le nom du fichier de cache ont été imaginé mais semblent assez archaïque. A discuter.
• 22 :
  • Amélioration de l'interface pour régler les options de vélocité et de magnitude, ajout des boutons pour pouvoir changer de 1 ou de -1 la valeur
  • Ajout de éléments d'interface pour pouvoir régler les SIGMA M et V. Un problème se pose :
    • L'option SIGMA comprend en fait deux options en une. La première est l'option SIGMA mais ensuite l'option contient un deuxième paramètre, comme par exemple M et V. La fonctionnalité de lecture des options ainsi que la procédure de réécriture du fichier d'entrée actuel ne suppporte pas ce genre de cas. Il faut donc trouver une nouvelle solution pour pallier ce problème
• 23 :
  • Réglage du problème de l'option SIGMA, le programme interprète maintenant correctement le paramètre de l'option SIGMA
  • Modification de tout le système de création des nouveaux fichiers pour pouvoir ajouter cette nouvelle option (le système antérieur ne pouvant pas s'adapter à ce genre d'option...)
• 24 :
  • Intégration du nouveau système de connexion à Simbad mis en place par Anaïs Oberto pour permettre d'utiliser le cache sans aucune connexion internet
  • Mise en place d'une combobox pour pouvoir gérer les options déjà existantes. Elle affiche donc toutes les options séléctionnées sur l'interface mais elle permet surtout de pouvoir voir les options originelles du fichier d'entrée. La comboBox permet aussi de supprimer ces options en cliquant dessus
  • Après présentation de la solution un moyen plus intuitif est imaginé pour modifier directement les options. Une zone de texte modifiable qui récapitule les options présentes sur le fichier ainsi que les options présentes dans l'interface

• 25 :

  • Recherche d'une solution pour pouvoir lancer la désérialisation de seulement quelques attributs et non de tout le fichier cache (trop long) pour vérifier que le fichier de cache correspond bien au fichier d'entrée et pour récupérer la valeur du rayon de recherche maximal. J'ai donc essayé de passer les champs que je ne voulais pas désérialiser en transient (mot clé pour dire qu'un attribut ne doit pas être sérialisé) mais même si je dis explicitement via ce mot-clé que cet attribut ne m'intéresse pas, tous les attributs sont néanmoins désérialisé. Cette méthode pour ne pas désérialiser l'intégralité de l'objet est donc pour l'instant non opérationnelle.
  • Mise en place de la zone de texte pour pouvoir avoir un aperçu des options actuelle en temps réel. Nous pouvons aussi directement régler ou modifier des options en écrivant directement dans la zone de texte
• 28 :
  • Mise en place des contrôles sur le fichier de cache et le fichier d'entrée pour s'assurer que les deux fichiers soient bien liés (si aucun contrôle n'est effectué nous n'avons aucune garantie que le fichier de cache et le fichier d'entrée traitent bien les mêmes objets)
  • Pour contrôler la cohérence des deux fichiers nous utilisons donc 3 critères :
    • Le rayon maximal : Le rayon de recherche du fichier d'entrée ne doit pas être plus grand que le rayon maximal du cache.
    • Le bibcode : Le bibcode des deux fichiers doit être identique
    • Le nombre d'entrées : Le nombre d'entrées (d'objet a comparer) doit être le même
  • Ces tests ne permettent pas de s'assurer à 100% que les fichiers soient bien liés mais ils limitent au moins les risques liés aux erreurs d'inatention de l'utilisateur...
  • Intégration de la page web qui contient le visionneur AladinLite (Pour avoir un rendu visuel de la région du ciel étudié) sur le projet grace à l'outil WebView de JavaFx qui permet de faire tourner un "mini-navigateur" web en Java. Il permet donc de faire des requêtes HTTP / HTTPS. Il prend aussi en charge les styles CSS et surtout il permet d'exécuter du code Javascript. AladinLite étant une API en Javascript, il est indispensable pour nous de pouvoir en exécuter.
  • Essais pour upload des fichier à partir de la WebView de JavaFx pour transmettre le fichier de sortie de COSIM à l'application web. Cependant lors de l'upload le programme lance une SEGFAULT et se coupe. Après recherches il est en effet impossible pour la WebView d'upload des fichiers pour des raisons de sécurité.
• 29 :
  • La solution choisie pour transmettre les informations nécessaires à l'API AladinLite est donc de stocker ces infos dans un fichier qui sera accessible via une requête HTTP par le serveur local qui héberge l'API AladinLite. Quand cela est nécessaire le programme JS fera donc une requête HTTP sur le fichier qui contient l'info et à partir des données récoltées il affichera les objets trouvés dans la BDD de SIMBAD.
  • Mise en place d'une zone de texte qui récapitule les infos les plus importantes issues du fichier de sortie.
  • Tentative de rendre interactive cette zone de texte pour pouvoir visualiser l'objet en question lorsqu'on clique dessus.
  • La zone de texte utilisée (TextArea de JavaFx) est trop limité en matière de possibilité d'interaction. Il faut donc changer de type d'objet. De plus étant donné la quantité du nombre de lignes à afficher les TextArea ne sont vraiment pas adaptées
  • Recherche pour trouver un type d'objet qui affiche le fichier de sortie et qui soit interactif.

• 30 :

  • Adaptation du code JS pour pouvoir remplir la zone de texte à partir d'une page HTML au lieu de prendre un fichier en entrée

  • Adaptation du code Java pour créer un fichier à chaque validation des paramètres
  • Le code JS vérifie toutes les 500ms par requête HTTP que le fichier obj (celui qui contient l'objet à afficher) n'a pas changée, s'il a changé l'API AladinLite affiche le nouvel objet
  • La page WebView chargé lors de la validation fait maintenant référence à l'objet passé dans le fichier crée
• 31 :
  • Correction de quelques bugs
  • Mise en place de boutons "suivant" et "précédent" pour pouvoir changer l'objet affiché dans AladinLite
  • Mise en place d'un filtre pour pouvoir afficher uniquement les objets voulut dans la zone de texte

Juin

• 1 :
  • Réglage de quelques bugs
  • L'affichage dans AladinLite prend maintenant donne uniquement les objets dans le rayon maximal de la recherche du fichier d'entrée lié
  • Recherche de nouveau types de zone de texte pour remplacer les TextAera. La librairie RichText semble fournir de bonnes solutions. Nottament l'objet CodeArea
  • Remplacement de la zone de texte TextArea par une CodeArea

• 4 :

  • Ajout de la ScrollBar sur la zone de texte (l'objet CodeArea n'a pas de scrollBar par défaut)

  • Cliquer sur un objet dans la zone de texte permet maintenant de changer l'objet cible de AladinLite selon l'objet choisi
  • La CodeArea se met maintenant à jour lors du changement de filtre, plus besoin de réappuyer sur valider
• 5 :
  • Tentative de rajouter des styles CSS sur la CodeArea
  • Ajout d'un compteur de lignes sur le CodeArea pour mieux se repérer
  • Découverte d'un bug lors du filtrage de certaines lignes
• 6 :
  • Tentative de régler le bug découvert la veille mais découverte d'un nouveau petit bug : la CodeArea ne se remplit pas automatiquement lors de la validation, il faut changer le filtre au moins une fois pour l'afficher
  • Réorganisation de la partie gestion des options de l'interface
  • Rédaction du rapport de stage
• 7 :
  • Tests de performances sur un fichier de 30 000 entrées. Le cache permet de passer de 220 secondes de traitement à 50.
  • Ajout d'un cercle qui représente le rayon de recherche
  • Les objets issus du catalogue Vizier concernés sont également ajoutés dans le rayon de recherche
• 8 :
  • Rendez-vous avec Thomas Boch (créateur de AladainLite) pour voir comment améliorer mon interface Aladin
  • Changement dans le fonctionnement d'Aladin. Il n'y a plus de serveur HTTP qui tourne en paralèle, désormais c'est le moteur Web de JavaFx qui charge directement les fichiers Html et Javascript.
  • Le passage des paramètres entre le Javascript et le Java se fait directement depuis le programme Java

• 11 :

  • Meilleure gestion du Thread (le thread qui se lance quand Cosim est exécuté)
  • Visite de ma tutrice pédagogique Agnès Braud
  • Correction de divers bugs avant la présentation aux documentalistes
• 12 :
  • Quelques retouches sur l'interface
  • Réunion avec l'équipe des documentalistes de Simabd pour présenter l'outil mis en place. Voici quelques remarques :
    • L'interface pour configurer les options ne comprend pas assez d'options à paramétrer.
    • L'interface de configuration et l'interface de sortie devraient être séparé en deux
• 13 :
  • Recherche d'un nouvel outil pour mettre en place la nouvelle interface qui sera beaucoup plus complexe
  • Mise en place du nouvel outil pour l'interface :
    • Test de NetBeans
    • Finalement l'outil choisi est "SceneBuilder" de Gluon
  • Mise en place de la nouvelle interface sur SceneBuilder
• 14 :
  • Mise en relation du Fxml généré avec SceneBuilder avec le code (ajouté les noms des éléments dans le Fxml et dans le code, ...)
  • Programmation des éléments de base de l'interface
  • On peut désormais construire le fichier de configuration avec l'interface (cependant la lecture des fichiers de configuration ne remplit pas les champs de texte ou les checkbox correspondant, pour l'instant il faut donc configurer le fichier entièrement à chaque fois)
• 15 :
  • Rédaction du rapport de stage
  • Réflexion et mise en place d'un plan pour la soutenance de stage
  • Ajout d'une nouvelle fenêtre (un nouvel onglet) pour la visualisation de la nouvelle interface
  • Problèmes non réglés pour la zone de texte du fichier de sortie. La CodeArea n'a pas de ScrollBar par défaut, étant donné que l'interface est désormais construite par le Fxml quelques problèmes se posent sur la zone de texte (qui vient d'une librairie externe) et de la ScrollBar
  • Ajout de la fenêtre de visualisation AladinLite. Quelques problèmes liés au Bibcode

Liens

• Librairie RichText pour l'interface (sous license BSD-2) : https://github.com/FXMisc/RichTextFX (release utiliée : richtextfx-0.9.0 )
• SceneBuilder : http://gluonhq.com/products/scene-builder/

Versions testables

• ...

Documentation

• COSIM : cds.u-strasbg.fr/twiki/bin/view/Documentaliste/RaccordDocumentaliste/COSIM
• Sérialisation Java : www.jmdoudoux.fr/java/dej/chap-serialisation.htm
• API AladinLite : http://aladin.u-strasbg.fr/AladinLite/doc/

Travail post stage éventuel

• Le changement de AladinLite pour AladinDesktop
• Mettre des couleurs dans les zones de textes
• Faire en sorte que la scrollbar suive les objets ciblé lors de l'utilisation des boutons suivant et précédent

Liste des améliorations à envisager

• ...

Bugs connus

• Le bug du nouveau fichier parfile qui s'écrit dans les deux fichiers (l'ancien et le nouveau) n'a pas été réglé
• Peut-être certains bugs lors de la lecture des fichiers parfile pour le remplissage de l'interface *