Préambule

Les premières lignes de QElectroTech remonte à 2006, celui-ci a été crée en tant que projet d’étudiant et n'avait pas pour ambition d'être ce qu'il est aujourd'hui. De ce fait, certains choix techniques qui on été fait à l'époque ne sont plus adapté à l'heure actuel (mauvais design, manque d’évolutivité, code spaghetti, code pas assez découplé, etc…). En 2012 le créateur de QElectroTech quitta le projet et donna la mains à Joshua (la personne qui écrit ces lignes), bien que celui-ci était très motivé il était autodidacte (et l'est encore) et aggrava encore plus la situation. 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

C'est l'une des parties la plus importante aussi bien d'un point de vue de temps de travail, que de changement profond.

  • Les fichiers élément (.elmt).

Les fichiers éléments sont un dériver grossier du format svg avec beaucoup de modification plus ou moins propre. Le nouveau format (.selmt ? scalable element ?) sera donc . -La partie graphique sera du vrai svg, concrètement il faudra utiliser le namespace svg dans le xml pour toutes la partie graphique. Avantage du svg :

  1. C'est un format éprouvé de longue date ainsi même si on ajoute de nouvelle chose graphique, pas besoins de ré-inventer la roue, le svg aura forcement ce qu'il faut pour enregistrer ça.
  2. Il faudra créer du code pour parser le svg, ce qui veut dire que l'on pourra importer un svg directement dans l'éditeur d'élément (il existe plein de site en ligne qui convertisse du dxf en svg)

-Les parties non graphique (texte dynamque, information, bornes etc…) seront en dehors du namespace svg, il faudra la aussi réfléchir à amélioré tout ça.

  • Les fichiers project (.qet).

Bien que ce format étais parfait pendant de longue année, celui-ci montre quelque limite d'un point de vue de la facilité de mise en œuvre. Le nouveau format sera : Un dossier zipper (lib zip) dans ce dossier on retrouvera plusieurs chose dont :

  1. Un fichier .qet grandement simplifier.
  2. Un fichier .sqlite contenant toutes les info du projet.
  3. Un dossier images
  4. Un dossier elements
  5. Un dossier titleblock
  6. Un dossier conf ou pref (a voire pour le nom)

Le fichier .qet aura la liste des folios dans l'ordre, dans chaque folio, la liste des éléments présent dans le folio ainsi que leurs coordonné (x y z)sous forme d'un chemin de collection, la liste des images avec leurs coordonné (x y z), le cartouche utilisé avec la tailles des colonnes/lignes nombre de colonne/lignes affiché ou non. Les images, élément et cartouches ne seront plus embarqué dans le .qet, mais dans leurs dossier respectif, ce qui en plus de la simplicité d'utilisation aura une taille très petite grâce à la compression zip (la plupart des fichiers étant du texte, ceux-ci se comprime très bien). Le dossier conf quand a lui contiendra entre autre choses toutes les configuration par defaut du projet (conducteur par défaut, folio et cartouche par défaut etc…) Le fichier .sqlite quand à lui contiendra toutes les informations nécessaire au projet, il sera facile de retrouver les information entre le .qet et le .sqlite par les uuid (element, folio et autres si besoins posséderont leurs propre uuid) la bdd contiendra entre autre chose :

  1. Une table pour les informations d'éléments.
  2. Une table pour les infos de folio.
  3. Une table pour les info général du projet.

Cette base de donnée ressemblera beaucoup à la classe project data base

Autre (toutes les petites et grosse chose à améliorer)

-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. 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)


-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


-infoKey et translated infoKey, mettre tout ça dans un seuil fichier au lieu de qetapp


-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.


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. 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.


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.

Imprimer/exporter