Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
refonte_du_code_de_qelectrotech [21/08/2020 13:15] – [Autre (toutes les petites et grosse chose à améliorer] black_sun_2012refonte_du_code_de_qelectrotech [10/02/2023 20:46] (Version actuelle) – [Autre (toutes les petites et grosse chose à améliorer)] black_sun_2012
Ligne 5: Ligne 5:
 C'est pourquoi un jour il faudra passer par une refonte très conséquente du code afin de remettre celui-ci à niveau, ce travail est difficilement quantifiable mais il est certains qu'il prendra beaucoup de temps, ainsi il ne sera commencé que quand toutes les fonctionnalité de base seront implémenter ( à l'heure actuel on peut considéré qu'il manque : le générateur de bornier, le générateur de câble, structure de projet +=-) C'est pourquoi un jour il faudra passer par une refonte très conséquente du code afin de remettre celui-ci à niveau, ce travail est difficilement quantifiable mais il est certains qu'il prendra beaucoup de temps, ainsi il ne sera commencé que quand toutes les fonctionnalité de base seront implémenter ( à l'heure actuel on peut considéré qu'il manque : le générateur de bornier, le générateur de câble, structure de projet +=-)
  
 +Le but entre autre est de découpler le code en plusieurs parties bien distincte, revoir des parties du code afin d'enlever toutes les rustines, reprendre de grande partie de code afin de mieux corresponde au fonctionnement actuel de qet. Une fois ces buts atteint, le code de Qet sera plus solide mais aussi plus facile à lire et comprendre pour les contributeurs externe..
 ===== Modification des format de fichier ===== ===== Modification des format de fichier =====
 C'est l'une des parties la plus importante aussi bien d'un point de vue de temps de travail, que de changement profond. C'est l'une des parties la plus importante aussi bien d'un point de vue de temps de travail, que de changement profond.
Ligne 37: Ligne 38:
 -QetDiagramEditor, il y a une quantité énorme de QAction membre de la classe, voir si il serais possible de mettre toute ces QAction dans une autre classe (ActionPool qui devrais être un singletone ou un QSharedPointer appartenant à Qetapp ? Bref il doit y avoir qu'une seul instance car la classe fera les connexion elle mêmes et les slot seront aussi dans cette classe.) QetDiagramEditor irais chercher les QAction dont il a besoins dans le pool, quand le signal triggered sera émis, le slot exécutera l'action. Souvent l'action est relatif au diagramme en cours, il suffira soit de retrouver le sender du signal (le diagram editor, puis retrouvé le projet courant) ou alors dans une méthode statique de qetapp retrouver le projet qui a le focus, une fois que l'on possède le projet en cours on connais tous le reste. -QetDiagramEditor, il y a une quantité énorme de QAction membre de la classe, voir si il serais possible de mettre toute ces QAction dans une autre classe (ActionPool qui devrais être un singletone ou un QSharedPointer appartenant à Qetapp ? Bref il doit y avoir qu'une seul instance car la classe fera les connexion elle mêmes et les slot seront aussi dans cette classe.) QetDiagramEditor irais chercher les QAction dont il a besoins dans le pool, quand le signal triggered sera émis, le slot exécutera l'action. Souvent l'action est relatif au diagramme en cours, il suffira soit de retrouver le sender du signal (le diagram editor, puis retrouvé le projet courant) ou alors dans une méthode statique de qetapp retrouver le projet qui a le focus, une fois que l'on possède le projet en cours on connais tous le reste.
 L'avantage c'est qu'on enlève une grosse partie du code de qet diagram editor (instanciation de QAction, connection, slot dans le QetdiagramEditor car il faut bien qu'il soient quelque part mais pourrais tout aussi bien être ailleur.) ainsi la classe se concentrera plus sur ce qu'elle doit réellement faire. L'avantage c'est qu'on enlève une grosse partie du code de qet diagram editor (instanciation de QAction, connection, slot dans le QetdiagramEditor car il faut bien qu'il soient quelque part mais pourrais tout aussi bien être ailleur.) ainsi la classe se concentrera plus sur ce qu'elle doit réellement faire.
-Il sera aussi plus facile de retrouver les QAction et slot, car présent dans une poignée de classe précise.+Il sera aussi plus facile de retrouver les QAction et slot, car présent dans une poignée de classe précise 
 + 
 +---- 
 + 
 +-Classe element information, revoir c'elle-ci car un gros micmac au fur et à mesure des évolutions de qet. 
 +De plus elle devra s'interfacer avec la bdd, elle ne devrait plus contenir les infos elle même mais plutôt d'outils afin de récuprer une info dans la bdd ou mettre à jours une info dans la bdd ainsi que signaler à l'élément qu'une info à été changer dans la bdd (par exemple après un undo) 
 + 
 +-Ajouter pour cette classe la possibilité d'avoir plusieurs référence (ajouté à la volé) pour un même élément (pas juste contacte aux 1 et 2). Par exemple un simple bouton poussoir est constitué de plusieurs référence (ou une seul si le fabricant propose un montage prêt à l’emploie) le bouton, le socle, le/s contacte/s, le voyant. 
 + 
 +---- 
 + 
 + 
 +-Le code des cartouches, à chaque fois j'ai un mal de chien à comprendre ce code, ça part dans tout les sens mais ça marche donc à voir si c'est utile ou non d'améliorer cette partie 
 + 
 + 
 +---- 
 +__Conducteur__ 
 +-Ajouter la notion de potentiel électrique. Quand un conducteur est posé, en parallèle un potentiel électrique est crée (une classe) ainsi quand un autre conducteur est posé celui-ci prendra les propriété définie dans le potentiel, mais si besoins l'utilisateur pourra redéfinir une propriété pour le conducteur uniquement. 
 +Cela corrige l'utilisation pas toujours efficace du "appliqué a l'ensemble des conducteur du potentiel" donc pour résumé dans les propriété d'un conducteur il y aura deux panneau : propriété du potentiel et propriété du conducteur. Par défaut le conducteur utilise les propriété du potentiel sauf si l'utilisateur indique explicitement d'utilisé une propriété d'une conducteur. 
 + 
 +-Dans le xml, le chemin des conducteurs peut être auto ou manuel. Contrairement à manuel, les points des chemins en auto ne sont pas écrit dans le code. 
 +Jusqu'à présent cela n'a jamais posé de problème car l'algo de création du chemin des conducteurs n’a pas changer depuis les début de qet. 
 +Le problème c'est que si à l’avenir l’algo devais changer, lors de l'ouverture d'un projet fait avec l'ancien algo sur une version de qet avec le nouvel algo les chemin des conducteurs automatique ne serais plus les même. Il faut donc aussi écrire les points du chemin en auto afin d'être sûre lors de l'ouverture d'un projet d'avoir exactement le même chemin. 
 + 
 +-La creation d'un conducteur est un mélange entre les événements souris d'une borne + un affichage fait depuis le diagram (Diagram::conductorStart / stop) + les undo sont gérer dans la class terminal (création conducteur et autonum) + le chemin est effectué par le conducteur, une vrai usine à gaz. 
 +Il faut externalisé tout, pour au minimum que la borne ne gère plus rien et le diagram non plus. Le fait d'externaliser tout ça pourra rendre nettement plus simple l'automatisation de création de plusieurs conducteur en même temps (par ex cliquer sur plusieurs bornes afin de toutes les lier ensemble au lieu de faire une à une les liaison entre borne) 
 + 
 + 
 +---- 
 + 
 +Revoir l'ensemble des fonctions membres to/from xml (au moins pour la sauvegarde dans le .qet) afin que la sauvegarde ne soit plus géré par les classes elles mêmes (élément, projet etc....) mais une classe spécifique uniquement destiné à cela. 
 +L'idéal serais de sauvegarder par le biais d'un plugins. Ainsi la sauvegarde (d'un .qet .elmt ou tout autre) fera appel à une classe abstraite et celle ci fera appel à une classe concrète qui sera un plugin, l'avantage sera qu'en plus des formats natif de qet, il sera très facile pour un contributeur externe de créer sont propre plugin afin de sauvegarder sous un autre format sans avoir à toucher et apprendre le code de qet.. 
 +Voir ce qui a déjà été fait avec la classe terminal strip item. 
 +Les avantages sont entre autre : 
 + 
 +  * Diminuer la taille des classes concerné afin de faire uniquement ce qu'elles sont censé faire (la manière dont elles sont sauvegardé dans un fichier ne les concernent pas). 
 +  * Avoir une classe qui gère tout ça, regroupé en un seul endroit et donc plus facile à maintenir et améliorer. 
 +  * La classe devrais probablement être une interface ainsi, si il y a des changements dans la structure xml du .qet au lieu de faire une rustine (comme c'est le cas actuellement) il suffira de crée une nouvelle classe héritant de l'interface, ainsi il est tout à fait possible d'avoir une classe pour chaque version de qet ou la structure a été modifier (par exemple un changement a été fait entre la version 1 et la 1.1 alors il existera une classe pour le .qet version 1 et une autre classe pour la version 1.1). 
 +  * Si à l’avenir qet doit sauvegarder le projet dans un tout autre format pour une raison X ou Y, encore une fois il suffira juste de créer une nouvelle classe héritant de l'interface. 
 +  * Si nous devions mettre en place les deux derniers point comme c'est fait actuellement (cad chaque classe gère sont to/from xml) cela serais vite ingérable notamment si il devais y avoir une nouveau format de fichier. 
 +  * la classe gérant le to/from xml devra probablement être friend des classes concerné. 
 + 
 +---- 
 + 
 +Les poignées utilisé pour modifier les formes primitive sont géré par les formes elle même, il serais mieux que les poignées soit gérer par une classe extérieure. Idéalement donner la forme en argument à la classe et le tout est géré par la classe (création des poignées, maj de la forme suite au déplacement des poignées, création de l'undo command) étant donné qu'il existe des formes dans l’éditeur d'éléments et de diagramme, il serais bien de crée un peu d'abstraction afin de mutualisé le code. 
 +Idée à la volé, une classe qui gère purement la partie mathématique des modifications, une autre qui gère la partis affichage, une autre qui gère la partie undo command, peut être envisagé un pattern decorator. 
 + 
 +---- 
 + 
 +Virer la classe qet graphic shape item, et créer une classe pour chaque type de primitive. 
 +Revoir la manière dont les shapes items sont sauvegardé dans le .qet afin que chaque type de shape ai sont propre xml (actuellement tous les type de shape item sont sauvegardé dans le même element xml). 
 +Faire au plus près du standard svg. 
 +---- 
 + 
 +Les informations de folio (titre, auteur, date, etc...) ne doivent pas être géré par le cartouche (un cartouche sert juste à afficher entre autre les infos) mais par une classe dédié, qui doit s'interfacer avec la bdd de la même manière que les informations d'éléments. 
 + 
 +---- 
 +La variable %folio du cartouche peut être utilisé n'importe comment, car d'un coté on peut afficher plusieurs variable (%id/%total) et d'un autre coté %folio est utilisé en tant que numéro de folio dans la nomenclature / sommaire, ce qui est faux. 
 +Il faudrait pourquoi pas garder la variable %folio uniquement pour le cartouche mais ne pas l’intégrer dans la bdd du projet et voir pour ajouter une nouvelle variable dans le diagramme qui sera utilisé pour le numéro de folio (à ne pas confondre avec la position du folio).  
 + 
 +---- 
 + 
 +Revoir les prefix d’éléments, actuellement c’est n’importe quoi…. 
 +Tout cela se déroule en deux parties distincte : 
 +  *Un fichier avec les lettres code en fonction du type d’élément (K relais, S bouton etc.…) pour chaque norme existante, ou norme personnalisé. 
 +  *Étendre de manière conséquente les types d’éléments dans qet afin d’être le plus exhaustif possible et donc coller au maximum à la réalité. 
 +  *Le prefix des éléments sera par la suite établie en fonction de leurs types est du fichier du standard utilisé. Rien ne sera écrit en dur. 
 + 
 +---- 
 + 
 +Revoir intégralement l'auto-numérotation qui est hyper compliqué, et géré avec la pile d'annulation. 
 + 
 +---- 
 +Ajouter un nouveau type d’autonum ‘’intelligent’’ celui-ci sera basé sur une formule qui devra contenir la variable %{prefix}. Ensuite pas besoins de changer de règle d’autonum entre par exemple moteur/contacteur/disjoncteur etc.… c’elle ci basculera toutes seul en fonction du type d’élément toute en conservant indépendament l’état dans lequel elle est pour chaque type : 
 +Ex soit une formule intelligente suivante :-%{prefix}%{seqt} (prefix + chiffre sequentiel 2 digit) 
 +  *disjoncteur 1 → D01 
 +  *contacteur 1 → k01 
 +  *moteur 1 → M01 
 +  *disjoncteur 2 → D02 
 +  *contacteur 2 → K02 
 +  *moteur 2 → M02 
 +  *bouton marche → S01 
 +  *bouton arret → S02 
 +  *transformateur 1 → T01. 
 +Tout ça sans jamais changer de formule, c’elle ci s’adapte en fonction de l’élément. 
 + 
 +---- 
 + 
 +---- 
 +Revoir les Xref afin que c'elle ci soit beaucoup plus souple dans leurs utilisations et ce individuellement (représentation croix/contact, afficher ou non, position auto ou manuelle, taille...) 
 + 
 +---- 
 +Agrandir le champ d'utilisation des Xref (cela nécessite de revoir en profondeur les Xref afin d'être suffisament abstrait dans le code) afin qu'elles puissent être utilisé ailleurs 
 + 
 +[[https://qelectrotech.org/forum/viewtopic.php?id=788]] 
 + 
 +[[https://qelectrotech.org/forum/viewtopic.php?pid=3009#p3009]] 
 + 
 +---- 
 +Tous les tailles des textes de schéma doivent être exprimé en pixels au lieu de points afin que ceux-ci aient la même apparence peut importe sur quel type d'écran ils sont affiché. 
 +Il est possible que cette modification soit effectué avant la refonte de qet. voir : https://qelectrotech.org/forum/viewtopic.php?pid=6267#p6267 
 + 
 +---- 
 +Revoir les textes indépendant des schémas, actuellement un texte peut être simple ou html, mais c'est le bordel à gérer + bug pour des raisons historique. 
 +-Ce qu'il faudrait c'est soit avoir deux types de texte indépendant, des simple et des html ainsi tout sera plus simple à gérer ou alors mieux gérer le fait qu'un texte soit simple ou html rien de bien compliqué au final mais cassera les textes existant dans tous les cas. La solution 1 est probablement la meilleurs, un poil plus de code mais mieux découpé. 
 + 
 +---- 
 +Classe projectconfigpage, la methode virtuel init() appel les methodes initwidgets et initlayout ainsi que readValuesFromProject ces méthodes semble être utilisé n'importe comment (un coup oui, un coup non en fonction de la classe dans lequel on se situe) enlever tout ça et laisser faire les classe toutes seule. 
 + 
Imprimer/exporter