Liste de liens :
Liste de liens :
Les objectifs se découpent en deux grands axes :
La sémantique à ajouter reste à définir mais dans un premier temps nous avons besoin de connaître dans le composant de rendu de graphiques interactifs de TXM :
Voir : Ticket #269 au sujet de la définition des fonctionnalités et des besoins du composant de rendu.
Après premières discussions :
Actuellement, dans TXM RCP, les graphiques sont calculés par les packages de stats utilisés (ex. FactoMineR), puis construits par le package 'graphics' de R et enfin, rendus dans TXM RCP par Java (Batik pour le SVG et SWT pour les images raster) à partir du ficher généré par R (fichier SVG, fichier PNG, etc.). Les fonctions du package 'graphics' sont des fonctions orientées tracé, ex. plot(), lines(), text(), legend(). L'appel à ces fonctions appelle l'implémentation de ces fonctions dans le device graphique R courant. Par défaut le device courant produit une fenêtre native à l'OS (exécutée par le binaire R). Les implémentations de ces fonctions SVG ou PNG du device par défaut (Cairo), génèrent des fichiers contenant les graphiques.
Les packages de calculs statistiques par défaut ou complémentaires (ex. FactoMineR ou CA) appellent les fonctions de tracé du package 'graphics' qui appellent donc les fonctions du device graphique R courant.
Le problème de ce schéma est qu'il n'est donc pas possible d'ajouter de la sémantique aux graphiques depuis R avec la chaîne actuelle (package de stats ⇒ package 'graphics' ⇒ device graphique R), c'est-à-dire en passant par l'interface et la signature des fonctions des packages 'graphics' et des devices graphiques R.
A noter que la Toolbox permet de récupérer des valeurs de résultats produits par R via le couple Rserve/REngine. La Toolbox définit différentes structures de données Java pour manipuler des structures de données R (ex. Vector, Matrix, etc.) et des structures 'étendues' liées à la textométrie (ex. ContingencyTable, LexicalTable, etc.).
A noter également que toutes les fonctionnalités de R et des packages R de production de stats ne retournent pas forcément de données. Certaines fonctions appellent directement les fonctions de tracé pour produire le résultat. La communication ne peut donc être faite que dans un sens. Cela peut être problématique pour certaines solutions envisagées pour l'ajout et l'exploitation de la sémantique. [ TODO: voir à quel point cela peut être problématique, sachant que les structures de données abstraites de la Toolbox (Vector, Matrix, etc.) dédiées au moteur de stats peuvent être passées directement à une lib Java de création de graphiques. On peut par exemple passer directement un vecteur récupéré depuis Rserve, pour créer un histogramme des valeurs propres, à la place d'utiliser la fonction R hist()]
Actuellement, dans TXM et si l'on prend l'exemple des AFC, une interface ICA est définie décrivant les spécificités d'une AFC telle que nous en avons besoin dans TXM. En plus de la création d'un fichier SVG, un objet Java est créé depuis les données produites par R et reçues via Rserve.
Les implémentations de l'interface ICA existantes et l'interface elle-même sont utiles à plusieurs choses :
La sémantique peut être ajoutée :
Se mettre en relation avec les développeurs de R afin de définir de nouvelles spécificités pour les packages 'graphics' et l'interface de devices graphiques R.
Pros
Cons
Ici l'idée est d'instancier les objets Java depuis R/rJava en leur passant des variables R.
C'est ce que fait iPlots lors d'un appel depuis R (ex. ibar(), iplot(), etc.). Avec cette méthode, nous ne créons pas d'objet Java de résultat mais créons directement le composant SWT/AWT/Swing de rendu de graphique interactif.
Pour resituer le contexte :
iPlots n'est pas un Device Graphique R mais un framework Java et n'est donc pas une interface aux fonctions de tracé du package R 'graphics' (ex. plot(), lines(), etc). Pour rappel, ce sont ces fonctions de tracé (les fonctions du packages 'graphics') qui sont appelées par des packages comme FactoMineR.
iPlots est donc une lib à utiliser en tant que tout, elle n'est pas compatible avec d'autres packages R non prévus pour, ni n'utilise le mécanisme 'normal' de production des rendus graphiques.
iPlots peut être utilisée directement dans R, avec les fonctions ibar(), iplot(), ihist(), etc. mais également utilisée directement en Java, en créant directement les composants graphiques de type BarCanvas, ScatterCanvas, etc. ou en développant ses propres classes et/ou canvas. Comme expliqué précédemment, en utilisant iPlots dans R, les instances Java sont en fait créées via rJava en passant des variables R.
La sémantique dans iPlots est ajoutée via le code Java d'iPlots et non pas via le code R, on peut donc parler ici de post-processing si iPlots est exécutée depuis R. Un exemple pour le point d'entrée de la fonction ibar() en R :
.iplot.iBar <- function (var, ...) { a<-.iplot.new(lastPlot<-.jcall(.iplots.fw,"Lorg/rosuda/ibase/plots/BarCanvas;","newBarchart",var@vid),"ibar") if (length(list(...))>0) iplot.opt(...,plot=a) a }
c'est la classe Java BarCanvas qui va gérer la sémantique ajoutée aux composants Java, puis les événements Java AWT, etc.
La sémantique dans iPlots semble limitée. Elle ne dépasse par le niveau de l'objet 'graphique' au sens statistique du terme, ex. histogram, scatter plot.
[TODO : Est-ce que le framework nous permet par exemple, par simple héritage, de pouvoir différencier un histogramme des valeurs propres d'un histogramme de distribution par partie ? Dans le sens de modifier les événements, les labels, etc.]
iPlots définit des objets de type PlotComponent, PPrimPolygon, PPrimCircle, etc. Ces objets contiennent uniquement une sémantique liée à leur type graphique (au sens de tracé) et possède des méthodes de tracé.
Un appel à ibar(), ihist(), etc. dans R court-circuite le device graphique R et utilise directement rJava pour créer ou modifier des instances de classes Java.
Les packages utilisant eux normalement le device graphique courant de R, cela signifie que pour chaque package qu'on voudra utiliser autre que iPlots, il faudra le recoder en R pour l'adapter à iPlots mais vu que nous devrons ajouter notre propre sémantique, il faudra également coder notre propre classe Java via le framework d'iPlots. Si l'on prend FactoMineR par exemple, il va falloir recoder plot.CA()) en R pour créer des objets Java/iPlots via rJava mais également ensuite créer des classes Java pour ajouter la sémantique propre à la fonction. Alors que dans le cas de divers objets dans TXM on a déjà un objet Java représentant le type de résultat et contenant toute la sémantique dont nous avons besoin.
Dans le cas d'iPlots utilisé depuis R/rJava, on a donc R qui produit un jeu de données et le composant graphique Java est créé directement. Les données des résultats du côté Java sont stockées directement dans le composant graphique dans des variables de type SVar.
Production R => Composant graphique Java
Le principe fonctionne mais ce n'est pas très propre niveau séparation et cohérence des données. Par exemple, si on veut implémenter une fonction d'export des données, il faut soit repasser par R, soit récupérer les données depuis le composant graphique. Un autre exemple, si on veut faire de la sérialisation de résultats, en général sérialiser des composants graphiques est déconseillé, le mieux est de sérialiser les données puis de recréer les composants graphiques.
Pros
Cons
soit :
Note
ipe$.issue.warning <- "Note: On Mac OS X we strongly recommend using iplots from within JGR.\nProceed at your own risk as iplots cannot resolve potential ev.loop deadlocks.\n'Yes' is assumed for all dialogs as they cannot be shown without a deadlock,\nalso ievent.wait() is disabled.\nMore recent OS X version do not allow signle-threaded GUIs and will fail.\n"
(Pour info JGR est un GUI/Frontend pour R développé en Java)
Ici le principe est de stocker tout type de résultat dans un objet Java intermédiaire, séparé des composants graphiques Java.
Comme pour ce qui a été fait avec l'interface ICA (ou les interfaces ContingencyTable, LexicalTable, etc.), il s'agit ici d'ajouter la sémantique propre à TXM via la Toolbox Java lors de la récupération d'un résultat depuis R. On pourrait parler de post-processing sur les données produites par R.
TXM crée un nouvel objet Java et conserve donc une trace en mémoire du résultat qui va permettre :
Dans le cas de TXM pour les AFC on passe donc par un objet Java intermédiaire, qui sert de cache entre autres choses. Les composants graphiques sont créés à partir de cet objet et peuvent communiquer directement avec le résultat produit dans les deux directions :
Production R => Données <=> Composant graphique Java
TODO: Vérifier si le framework R de la Toolbox permet de modifier directement une donnée dans R via REngine (uniquement lecture ou lecture/écriture ?)
Si c'est le cas on a aussi une communication bidirectionnelle vers R :
R <=> Données <=> Composant graphique Java
permettant d'avoir un état cohérent entre les données R et les données Java.
Pros
Cons
A partir de ces objets Java (ex. ICA, Diagramme de distribution par partie, Histogramme des valeurs propres, etc.), il faut ensuite rendre le graphique, donc créer le composant graphique SWT, tracer le graphique et mettre en place les interactions utilisateur et les liaisons avec les composants SWT annexes (ex. masses, contributions, etc.).
Plusieurs solutions sont envisagées pour le moment :
Continuer à utiliser le format SVG comme pivot via l'ancien device RSVGDEvice ou via le nouveau device Cairo-svg puis afficher ces SVG dans SWT via Batik ou autre. Le problème de cette méthode est que comme R n'ajoute pas de sémantique dans les fichiers SVG il est extrêmement difficile de dire quelle balise SVG correspond à quel élément du résultat, en particulier avec le nouveau device Cairo-svg qui n'utilise plus la balise 'text' mais un système de glyph/path rendant impossible de détecter un label ou une légende. Il s'agit donc ici de post-processing sur le fichier SVG et de déduction en fonction du type de balise et de la position de la balise dans le fichier (ex. les points-lignes sont tracés avant les points-colonnes par le device graphique R donc j'en déduis que ces x lignes sont des points-colonnes)
Cons
Deux solutions sont envisagées pour la gestion des événements :
Modifier l'arbre DOM dynamiquement et gérer les événements via les composant Java2D.
Cons
Injecter les valeurs, la gestion des événements, etc. directement dans l'arbre DOM SVG Java.
Pros
Cons
Créer les graphiques via Java en utilisant une lib de création et de manipulation de graphiques (ex. JFreeChart, iPlots Java, etc.) ou directement en Java2D. Une fois qu'on a un objet de type ICA, Histogramme des valeurs propres, etc., à partir de ce dernier on crée le composant de rendu de graphiques interactifs.
Pros
Cons
[TODO : à confirmer/infirmer, en attente réponse liste Rosuda et/ou recherches supplémentaires] Pour l'embed d'iPlots, plusieurs solutions semblent possibles :
1) Continuer à utiliser Rserve donc utiliser iPlots en tant que lib graphique Java
Pros
Cons
2) Lancer R via JRI, faire l'embed depuis R/rJava ( : TODO: ou, à vérifier, lancer TXM RCP depuis R/rJava pour partager la même JVM)
Cons
Pros
Cons
Le développement pour l'utilisation d'iPlots depuis R/rJava sera sans doute plus long que l'alternative de passer par un objet intermédiaire et d'ajouter la sémantique dans le jeu de données en Java. Une première 'analyse' sur les AFC :
Cas 1 : iPlots depuis R/rJava :
Cas 2 : R + post-processing dans un objet Java
Pour ce 2e cas, on pourra également utiliser iPlots en tant que lib graphique, en lui passant l'objet de résultat en Java mais dans ce cas il faudra ajouter cette étape :
[ TODO: Voir si le scatter plot de base d'iPlots peut être utilisé pour l'AFC. Mais comme expliqué précédemment les canvas Java proposés par iPlots sont trop encapsulés, cela nécessitera donc a priori soit d'hériter de la classe ScatterCanvas et de rédéfinir/redévelopper une grande partie de la classe, soit de modifier le code source, ne serait-ce que pour la traduction des items des widgets mais le problème semble aussi se poser pour la gestion des événements]
L'exemple de l'AFC ci-dessus n'est en plus pas très bon car les classes Java de 'données de résultat' sont déjà codées donc là c'est clair que le temps de développement sera extrêmement plus court dans le cas de la solution avec JFreeChart mais le schéma reste le même pour n'importe quel graphique. Le cas d'iPlots depuis R/rJava ajoute la phase du redéveloppement en R donc a priori le développement sera plus long. Notamment car il y a une phase d'analyse du code source des packages R qui peut être ardue mais même en terme de dév, ce que j'appelle post-processing consiste en fait à faire des liens entre différentes données reçues donc ça reste normalement très simple.
[TODO:]
(par curiosité, même question pour le moteur de corpus bien que dans le code source, l'abstraction ne semble plus vraiment respectée)
(la réponse à la question impactera fortement le développement dans l'éventuelle utilisation de iPlots et/ou si la sémantique est ajoutée directement dans R. Pour infos si l'utilisation à distance est abandonnée, je crois que Rserve devient inutile, toutes les communications avec R auraient pu être faites via rJava ou sur le même principe que la lib native pour CWB a priori)
Suppose l'utilisation d'un navigateur intégré ou bien d'un ScriptEngine Java Javascript (Nashorn, Rhino…) ayant au moins l'API SVG.