On ne le sait pas encore, mais Joshua aimerai faire une refonte du code en profondeur, ce serait un nouveau logiciel avec des éléments au format SVG, et qui serait incompatible avec vos anciens projets.
Oui c'est un truc que j'aimerais faire, mais ça ne sera pas pour la 0.8.
Un petit sondage serait à mon avis pertinent ....
Je comptais en faire un pour la 0.8 peut être en passant par framform histoire que la prochaine grosse fonctionnalité soit profitable au plus grand nombre.
En revanche pour le svg il n'y aura pas de sondage, ce sera imposé mais voici quelque explications:
à la base le format de fichier des éléments est très proche du svg, puis avec le temps il l'est devenue de moins en moins....
Avec le recule et l'expérience (si je peut me permettre) je me rend compte que c'est une grosse erreur, pourquoi réinventer la roue (notre propre format) alors qu'une belle roue qui dispose de plus de fonctionnalité que nous en avons besoins existe et en plus est standardisé (svg).
Le xml dispose d'un système d’espace de nom, qui pour résumer permet d'inclure plusieurs norme xml (le svg par ex) au sein d'un même fichier xml. Ainsi le fichier .elmt aurai deux parties : un sous ensemble 100% svg et un autre propre à qet (borne, texte dynamique, info d'élément etc....).
Pour moi en tant que dev ça m'arrange bien la vie car :
-Si un jour je veut ajouter un nouveau truc graphique, par exemple une courbe de Bézier, le format svg possède déjà tout ce qu'il faut pour enregistrer ça, pas besoins de réinventer la roue qui en plus sera probablement moins bien que ce que propose le svg (c'est du vécu).
-Réduction du code coté éditeur de schéma, actuellement on parse le fichier .elmt pour créer toute la partie graphique. Avec le sous ensemble svg pas besoins, Qt possède déjà tout ce qu'il faut il me suffit de donner à la bonne classe le bout de svg puis il me ressort l'image de l'élément.
-Mélange des deux précédents : Avec le format actuel si j'ajoute une courbe de bezier, je suis obligé dans l'éditeur de schéma de codé un truc pour faire le rendu de la courbe depuis la description xml, alors qu'avec le svg, ba absolument rien à faire je donnerais toujours mon bout de svg à Qt qui lui me ressortira tout comme il faut.
Pour vous en tant qu'utilisateur.
-Format standard et ouvert, cad que vous pouvez créer/récupérer un svg puis l'importé directement dans l'éditeur d'élément tout simplement, pas de bidouille ou hack tordu à la scorpio 
.
Bon attention si vous importez un truc de ouf genre ça il est évident qu'il n'en sortira rien, ce sera une implémentation basique du svg (uniquement ce qui est utile à qet), on code pas un éditeur svg 
, mais je resterais ouvert par exemple si un truc sympa existe en svg, mais pas dans qet de l'implémenter.
-Sur le net il existe une multitude de convertisseur dxf -> svg.
-Redimensionnement, c'est pas prévu, mais pas exclu non plus car svg est prévu pour (cas concret de l'avantage d'utilisé un format standard).
-De l'animation, encore une fois pas prévu, mais svg sait le faire.
Mais tout cela est une partie d'un chantier beaucoup plus gros dont entre autre un nouveau format de fichier pour les projet (.qet) qui serais en fait une archive zip.
Encore une fois je ne vais pas faire la liste des avantages, mais il y en a pas mal et ça ouvre la porte sur beaucoup d'autre chose.
Bien entendue cela représente une bonne quantité de code à ajouter et modifier, et ce serais donc le bon moment pour faire une refonte sur des truc tordue que l'on traine depuis un moment (bonjours les couches de rétrocompatibilité) qui pollue le code.
Tout ça, ce sont des choses que je voie avec le recule et l'expérience (si je peut me permettre encore une fois) qui à mon avis seront nécessaire un jour ou l'autre.
Tout ça mènerais à un fork de QET (et donc l’abandon de QET), afin de repartir sur un nouveau logiciel et surtout un nouveau format de fichier mieux réfléchie.
Bon je vais m’arrêter la, le post est déjà bien assez long, et je pourrais écrire un romans sur tout les idées que j'ai vis à vis de qet.
