Search options (Page 20 of 33)

https://qelectrotech.org/forum/viewtopic.php?id=1382

Puisque on est en train de parler du format svg, il y a aussi quelque chose à laquelle je pense depuis un petit moment.
Alors c'est un truc qui aurais été possible avec le format actuel (.elmt) mais ce format n'a pas été pensé pour (et serais donc une sorte de rustine si devais être implémenté).
Avec la création d'un nouveau format (.selmt ?) ce 'truc' peut être pensé dès la conception.
Allé trêve de bavardage

Avoir plusieurs représentation graphique d'un même élément.
Je m'explique :
Vous créez un élément contacte, ensuite vous lui crée plusieurs 'apparence' ouvert, fermé, ouvert tempo travail, fermé tempo travail etc...
Pour chaque apparence les propriétés changeront, pour un contacte les numéro de bornes changeront mais aussi le type (tempo, NC, NO etc....) les informations etc....
Ensuite sur l'éditeur de schéma vous posez votre élément puis dans les propriétés de celui il y aura la possibilité de changer d'élément (oui car au final ce n'est pas que l'apparence mais toutes les propriétés qui vont avec, donc pour résumer, ce qui définit un élément).
Les deux seul contrainte serais les bornes qui devront resté au même nombre, le changement du nombres de bornes risque d'être complexe à gérer, et la seconde l'emplacement des bornes (et encore celui-ci j'en suis pas sure), bon au vue des possibilités les contraintes me semble mineurs.

Bien entendue j'ai pris en exemple un contacte mais ça peut être n'importe quoi d'autre.
-Une carte automate, de nombreux constructeur crée des cartes rackable ayant la même taille le même nombre de bornes...
-Un capteur, changer facilement entre inductif, capacitif, ultrason etc...

Bref voila une des nombreuses idée que j'ai (quand je dit que je pourrais bosser des année sur qet tellement j'ai d'idées).

Comme dit au début ce n'est pas le fait de passer au svg qui permettra ça, mais bien de revoir le format de fichier .elmt
Après l'utilité de la chose, je vous laisse juger (Dans tous les cas, le format de fichier sera pensé pour afin de ne pas fermer la porte).

Revision: 5819
Author: blacksun
Date: 2019-04-02 19:36:32 +0200 (Tue, 02 Apr 2019)
Log Message:
-----------
Improvement : minimize the unwanted gap of the top right folio of the view

J'ai encore amélioré voir supprimé (c'est comme les conducteurs fantôme, je comprend pas pourquoi ça agit comme ça) le problème du bord supérieurs gauche du folio qui est décalé par rapport à la vue.
Pour les schémas existant avec ce problème, il suffit de tout sélectionné (ctrl+a) déplacer un petit coup par exemple flèche haut puis bas (comme ça tout revient à sa position initial) et le problème est réglé.
Attention fait bien les mouvements avec retour à la position initial vous même, si vous faite une annulation (ctrl+z) ça ne sera pas pris en compte.

Oui c'est un truc que j'aimerais faire, mais ça ne sera pas pour la 0.8.

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.

Avec le dernier commit encore plus simple, sur les éléments posant problème tu copie le champ problématique, tu l’efface puis tu le colle problème réglé.
(En fait ça colle avec le retour chariot, mais dans le code on efface tout les retours chariot et nouvelle ligne qui sont écrit dans les champs d'information d'élément).

Normal il faut aussi enlever les 

Pour info les derniers commits enlève les 'retour chariot' et 'nouvelle ligne', uniquement sur les nouvelles information renseigné, cad que ceux existant dans vos projet ne seront pas résolut, pour ça un simple éditeur de texte réglera le problème.

https://doremifaso.ca/archives/unicode/latin1.html

Solved with comit 5813.
Wait for new build.

Very strange, I don't know why the previous code bug.

Je comprend bien que c'est dommage, mais je peut pas me permettre pendant 6 mois d'apprendre le format dxf (et donc stoppé le dev de Qet, et j'avoue que ça me botte pas non plus) alors qu'il reste une quantité astronomique de chose à apporter à Qet ( et ça, sa me botte )
Avec Laurent on s'est posé la question de laisser ou non l'export dxf.
Nous avons choisis de le laisser mais de le marquer expérimental.

Nous y voila, c'est la dernière ligne droite avant une RC1 de QET 0.7,
Il n'y aura donc plus de nouvelle fonctionnalité (même mineur), en revanche il est encore temp de faire remonter les petits défauts et/ou modifications pouvant être apportées aux nouveautés de cette version, durant la période de RC, afin d'avoir une version 0.7 la mieux finie possible.

Revision: 5775
Author: blacksun
Date: 2019-03-10 18:58:33 +0100 (Sun, 10 Mar 2019)
Log Message:
-----------
Element editor :
The font of the dynamic text field can be edited.
The font of the static text field can be edited.
The color of the static text field can be edited.

La police des textes d'éléments est paramétrable depuis l'éditeur d'éléments.
Par la même occasion le travail a aussi été porté sur les textes statique (police + couleur de texte, qui anciennement ne pouvais que être en noir et blanc).