marsante a écrit : ↑05 sept. 2020, 12:13
J'ai fait un première pull request ce matin pour l'ajout du tactile.
C'est mergé, la
démo est à jour, je le ferais régulièrement si je vois des pulls requests pour tester facilement les nouvelles implémentations.
J'ai vu qu'il y avait beaucoup de correction pour l'orthographe dans le commentaires. J'ai vraiment des soucis de ce coté, pour résumer simplement si je fait pas très attention à décortiquer chaque lettres de chaque mot au moment ou je lit (c'est pire quant j'écris) je les voit tout simplement pas. Pour moi à la simple lecture "description" ou "desciption" c'est pareil, ça me saute pas du tout aux yeux ni ne me parait évident. Du coup me relire et me corriger me prend beaucoup de temps et d'énergie. Alors pour les commentaires du code que de pensais de toutes façon provisoire j'ai laissé tombé. Je ne pensais par contre pas qu'il y en avait autant fautes, désololé pour ça, je vais tout de même essayer de faire plus attentions mais ce sera jamais vraiment top.
marsante a écrit : ↑05 sept. 2020, 12:13
J'ai copié le code existant et remplacé les mouses events par des touchs events, je n'ai pas testé en condition réelle par contre.
J'ai pensé aux tactile mais je l'ai pas implémenté car les cas d'usages ne sont pas les même qu'avec la souris et il faut repenser le déclenchement d'évènements différemment. Un exemple à la con est celui de la mise en évidence de l'élément qui va être supprimé quant on utilise la gomme. Avec la souris je vérifie l'état de l'élément sélectionné à chaque déplacement de la souris ('mousemouve') et déclenche des éléments si il ya changement d'élément en fonction de l'état du dessin à ce moment la via les propreté de l'objet
(utiliser 'mouseover' et 'mouseout' n'est pas une bonne idée pour cela car on se retrouve avec des cas à la con comme quant une forme est survolé tellement rapidement que l'évènement n'a pas le temps de se déclencher ou quant on dessine et que l'on lève le bouton de la souris en dehors du dessin).
Avec du tactile je pense qu'il faudrait déterminer l'état du dessin a chaque tapes sur l'écran (+ déclencher les actions de dessin si un outils de dessin est choisi à ce moment la jusqu'au levé du doigts ou dans ce cas l'action de dessin serai exécuté à chiques 'touchmove').
Enfin bon faudra de toutes façon faire des tests d'usages.
marsante a écrit : ↑05 sept. 2020, 12:13
Je vais essayer d'ajouter une fonction "effacer tout", ça me fera un bon exo vu que la logique change pas mal du canevas je trouve.
Attention car chiques élément du dessin est lié à une description du coup supprime t'on les descriptions avec ?
Sinon quant on supprime un description (croix rouge à la au bout de la ligne de description), on supprime aussi tout les élément du dessin attaché à la description.
marsante a écrit : ↑05 sept. 2020, 12:13
Concernant les remarques :
Si je comprends bien l'organisation future de la fonctionnalité, la librairie SVG.js sera placée dans le module de base et le JS du prototype sera à placer dans les formulaires qui en auront besoin via un sqlinstall ? Si c'est exact on pourra custom le code et notamment
pour sélectionner l'outil le plus utilisé par chaque profession ?
J'aimerai que ce champs puisse être configurer dans le yaml qui décrit un formulaire comme n'importe quel autres champs, avec ces propre propriété spécifique comme le choix d'un backround, la taille du schémas et d'autres trucs comme l'outil sélectionné par défaut ou même des descriptions pré-remplis.
Par contre je pense pas du tout placer du js dans la description du formulaire. Pour moi tout doit être gérer en instanciant la classe js dédié à la gestion du champs schémas. La macro twig qui rend le champs ne devrais renvoyé que peut de html (genre un <div> avec un id spécifique et les class qui vont bien pour l'afficher convenablement par rapport au autres champs) mais renvoyer en plus une balise <script> avec le nécessaire pour instancier une objet champs schémas, je pense que le reste du html pour le champ devait être produit par le js affin que l'affichage du champs puisse être versatile.
J'ai déjà pensé la classe js pour le champ schémas extensible pour ses outils de dessin (via la sous class
DrawTool, je voudrai que les éventuels modules puisse étendre la class
DrawSVG pour y ajouter d'autres outils de dessin qui leur serait spécifiques.
A ce propos je trouve mon système de class d'outil de dessin mal foutus : je suffixe dans le nom le la class le nom de l'outil (par example "DrawTool_square") et près j'instancie la class avec un
eval des enfers tout pété :
alors que l'on pourrais crée les outil de dessin dans un array d'objet :
Code : Tout sélectionner
this.DrawToos = [
'square': {...},
'circle': {...},
'pen': {...},
'rubber': {...}
];
A noté qu'il existe du type d'outil de dessin (le second type n'est pas vraiment un outil de dessin du coup il faudra surement changer le nom de la class pour lui donner une sémantique plus correcte) :
- les outils de dessin à proprement parler (squre, circle, pen) qui dessine des trucs (ajout d'élément au SVG).
- les outils qui font des actions, le seul représentant de se type pour le moment est 'rubber' mai je pense qu'il en faudra d'autres comme par exemple un truc pour avoir la description d'un élément au survol de la souris.
C'est pour cela que je pense qu'il faut ajouter une propriété type au outils de dessin (type: 'drawtool' ou type: 'actiontool').
Il faut bien sur que les outil implémente les méthodes standard tel que décrites dans la class
DrawTool (
beginDraw,
doDraw,
endDraw pour les outil de dessin, elles seraient différentes pour les outils de d'action).
marsante a écrit : ↑05 sept. 2020, 12:13
Je n'avais pas trop saisi l'intérêt de donnée structurée pour un schéma, mais avec l'exemple j'ai enfin compris. Le champ description est top pour par exemple faire un schéma avant et un après, ou pour annoter une imagerie. Actuellement par défaut on ne peut pas modifier la première description, pareil que pour la fonction "effacer tout" ça peut être un bon exo pour moi de trouver pourquoi.
marsante a écrit : ↑05 sept. 2020, 13:52
Je viens de capter en regardant de façon plus approfondie le code que le fait que le premier champ de description n'est pas modifiable est une fonction voulue et pas un bug my bad
.
C'est en effet voulut vu que chaque élément du dessin doit être rattaché à au moins une description la première prend le rôle de description par défaut en ne peut pas être supprimé. Par contre au lieux de fixer son contenus à "Aucune description" on aurai pu le rendre modifiable. Par contre cette description n'est pas supprimable, si on veut la "reste" il faudra lui ajouté un bouton supprimé qui surprime les éléments du dessin lié sans supprimer la description elle même.
A noter que chaque description possède un numéro qui lui est normalement unique (calculé en ajoutant 1 au numéro de la dernière description), celle par défaut à le numéro 0.
Autres chose à noter : quant un supprime une description ne peut pas annuler l'action avec les bouton annuler et refaire.
marsante a écrit : ↑05 sept. 2020, 12:13
Par rapport à l'idée de la fonction que j'ai du module ostéo c'est déjà parfait en l'état, pour les autres besoins je ne me rends pas compte.
Concernant tout ce qui est stockage de la donnée perf etc etc j'y connais rien donc je ne me prononcerai pas
.
Sinon si vous avez envie de m'orienter pour que je vous aide, n'hésitez pas.
Pour le stockage, le json semble être la solution, les pb de perfs pour la recherche pourait être en partis limiter en la couplant à d'autres critère (lié à un patient ou une consultation particulière), bref a voire à l'usage.
Bertrand a écrit : ↑04 sept. 2020, 15:49
A voir si MariaDb gère aussi, car on assiste quand même à un switch mysql->mariadb dans les distrib apparemment ...
J'ai noté Mysql mais sa fonctionne tout pareil avec MariaDB (d'ailleur j'ai tésté avec MariaDB)
Bertrand a écrit : ↑04 sept. 2020, 15:49
Pour l'implémentation, je n'ai pas encore la vision complète en tête. La gestion des backgrounds est une question, l'utilisation d'une photo / images dicom vient la rejoindre.
Je dirais que la source du background devrait entrer dans le json : la provenance (bitmap / dicom / ...) et l'url ou l'identifiant permettant de le récup.
Faut-il attacher le data_type au groupe medical ou en créer un spécifique ... là-dessus, faut voir les tenants et aboutissants (liés à la gestion de la data et au comportement en cas de réédition secondaire), voir le code de msObjet::createNewObjet()
Pour le moment j'ai pas encore non plus d'idée pour gérer les annotations sur les ressource issue de phone capture mais il faut en effet prendre en compte un propriété pour gérer le backround et sa provenance. Après tous pourrai être géré l'installation de la class "DrawSVG" qui pourrai prendre un json comme param et faire que le champ d'édition de schémas s'adapte tout seul en fonction de la source et du contexte.
Pour le modules ostéo, désolé je pense pas pouvoir aboutir à un résultat très rapidement (peut être d'ici la fin du mois), je vais avoir peut de temps pour travailler dessus et je voudrai pas bâcler le turc pour ne pas aboutir à un truc boiteux qu'on trainerai au final comme un boulet. La je doit laisser ça pour les 15 jours à venir du coup je laisse Marasante avancer dessus comme il peut durant ce temps la.