1

(84 replies, posted in Scripts)

About closed polygon, see const QDomElement PartPolygon::toXml(QDomDocument &xml_document) const

if (!m_closed) xml_element.setAttribute("closed", "false");

So if the the polygon is not close, the attribute is not present.

In svg there is not close or open polygon.
There is polygon (close) and polyline (open)

2

(84 replies, posted in Scripts)

I don't know what lib you use to write your converter,
but if you use Qt, you probably can find the bottom left corner by create an instance of QFont and QFontMetric with the specified font read in the xml.
If not (Qt) I think you can easily find lib to achieve this job.

About the rotation of the text in svg, there is the attribute rotate but apply the rotation for each character of the text.
https://developer.mozilla.org/en-US/doc … ement/text
For rotate text in svg you need to use a transformation https://developer.mozilla.org/en-US/doc … /transform
With Qt you can see https://doc.qt.io/qt-6/qtransform.html

3

(84 replies, posted in Scripts)

Hello Plc-user,
I'm happy to read you are currently working on an elmt to svg converter, and wow very very good job.

About the color : like you say, you can drop it for now.

About text : For historical reason (and bad choices I made), how the texts are managed in the elmt file is a mess.
With the links Laurent give, you can see there is several way how the position of the text are saved, and no one are good in sense of svg.

If you read PartText.cpp, the function toXml, you can see the position x and y is the position of graphicsItem of the text but not the text itself (in the same class read the function void PartText::adjustItemPosition(int new_block_count)).

And in the class PartDynamicTextField it's approximately the same thing.

In svg, the position of the text is the base line https://developer.mozilla.org/en-US/doc … ement/text and the base line is bottom left of the text (like you say in previous post)
So to resume the situation, it will be very difficult for you to convert the "qet" position to "svg" position, withouse the baseline of the current used font. From my point of view try to approximate the position in first time.

One other thing, the text size with Qt (see QFont class info) can be pixel size of point size. Until some year we used default value (point size) and have no problem because QElectroTech was used in with screen with same dpi. But now there is a lot of screens with different dpi and the text are not displayed in same size from screen to another. This is why now (and if we had known that before, we would done it from the start) we use pixel size.
Point size => Same physical size one screen no matter the dpi.
Pixel size => Same pixel size on screen no matter the dpi.
Consider the font size are in pixel size even if it's was not true when the element was saved.

I probably forget some information don't hesitate to ask us.

I don't know if you are aware or not but in future (long ?) I plan to rewrite a large part of QElectroTech (To solve lot of problem, bad choice, base design, etc...) one point of this rewrite is to use true svg for the graphical aspect of element and not an ersatz of it.
May be when this time will come I will used your code for that (if you are ok).


some link about text in Qt

https://doc.qt.io/qt-5/qfont.html
https://doc.qt.io/qt-5/qfontinfo.html
https://doc.qt.io/qt-5/qfontmetricsf.html

Don't forget, we don't draw directly text in the folio, but draw text inside a QGraphicsItem and the position is the position of this item, not the baseline of the text.
https://doc.qt.io/qt-6/qgraphicsitem.html

Joshua

4

(128 replies, posted in Bar Fourre-tout)

Bonjour Bernard, merci pour les encouragements ça nous fait toujours très plaisirs nomicons/smile.

WHAAA, j'ai déjà eu des armoires très très bordélique avec rien à jours etc.... mais la c'est le ponpon, j'aime bien les planches de bois, même pas un petit rail DIN pour tenir tout ce petit monde en place... Bon courage pour remettre tout en place et au normes, mais quelle satisfaction une fois fait nomicons/smile

C'est de la réparation d'urgence réalisée sur de nombreuses années.

Pour le coup l'urgence c'est de refaire tout ça avant que ce monstre devienne une panne (le TSX 17 est un tout petit peut obsolète).

Damn nomicons/grin
it's work with the folio variables, but work only half with project variable...
Let's work.

This part of code (variable) is also a big part to totally revamp, to be easy to maintain and also more powerful for user.


EDIT

Fixed

Fixed, thanks for report

It's not a bug it's a feature nomicons/grin .
Seriously, the autonumbering don't take count of deleted element, and so by consequence the numbering stay at the same state and cause the gap you describe in your screenshot

I Will check it today.

About the wrong Xref (NC instead of NO) check the properties of the NO contact, the parameter of slave type is probably set to NC change it to NO in the element editor.

Bonjour JC,
je vais essayer de prendre du temp demain pour te répondre.
En attendant peut tu être plus précis sur les points où tu bute.

C'est déjà le cas, je te laisse voir la vidéo plus haut à 22min

Bonjour, il n'y a pas de module d'implantation il s'agit uniquement de dessin avec des rectangle à l’échelle.

Non ça va au niveau des démarches en ligne, c'est juste que depuis le regroupement des 3 communes voisine le nom de la commune à changer..... mais a quand même gardé l'ancien nom (comme les deux autres commune d'ailleurs) du coup c'est soit l'un soit l'autre en fonction duquel existe dans la base de donné du truc que tu consulte.

Ce que j'en pense : je comprend l’intérêt de créer une association afin de faciliter bon nombre de chose, hélas toi comme moi avons un temps libre limité. Je pense qu'il vaux mieux laisser tomber actuellement, prend soins de toi c'est plus important que de te créer des soucis supplémentaire, moi de mon coté je n'ai clairement pas le temps de m'occuper de ça (en ce moment je n'ai même plus le temps de coder nomicons/sad )

Et non on ne va pas créer un compte auto-entrepreneur pour du bénévolat.

Pour info (Laurent et les autres) si vous avez l'habitude de lire linuxfr, les journaux de https://linuxfr.org/users/jehan au sujet de gimp sont intéressant, entre autre il parle des difficulté qu'ils ont à ceux sujet malgré l'age et la base d'utilisateurs de gimp (qui doit être sans commune mesure avec qet) tous ça pour dire qu'il ne faut pas trop se tracassé avec ça, on est juste trop petit et en plus un "marché" de niche.
Lire les retours des dev de logiciel libre et gratuit permet de comparer nos experience et je trouve qu'on s'en sort pas trop mal (surtout quand on regarde d'où l'on vient)

PS:
Je trouve ta photo de profil plus sympa que l'ancienne nomicons/wink.

Corrigé.

Bon j’arrive un peu en retard sur le sujet…. nomicons/grin

Bon alors déjà écrire les choses en dure dans le code c’est non. Je comprends bien que dans un premier temps ça arrange tout le monde, mais ensuite après plusieurs versions on veut faire un truc avec plus d’automatisation et/ou poussé tout en gardant la rétrocompatibilité et là je me casse les dents un truc de fou, et de plus du côté utilisateur il y a toujours des pertes qui se produisent….

Aujourd’hui la seule bonne manière c’est à l’utilisateur de faire tous les types de contact dans sa propre collection. Donc pour donner mon avis c’est non pour mettre tous ça dans la collection officielle. QElectroTech semble maintenant pas mal utilisé (aux vues des retours que l’on a) et tout le monde s’accommode de cette lacune donc ça continuera ainsi. Je préfère 1000x ne rien coder (et encore plus si c’est coder un truc « en attendant mieux ») mais une fois lancer faire un truc complet, solide et réfléchie ensemble.

Ensuite voici comment je ferais la chose, et j’y ai déjà réfléchi par le passé.

Il faut que les bornes d’élément possèdent plus de propriété et pas que pour les contacts, ainsi on sait quoi faire avec la borne (ça résous déjà le problème que soulève galexis au sujet des contacts inverseurs) il faut que les bornes possèdent leurs propres textes (résous le problème des rotations de texte).
Avoir en dehors du code (un fichier) la liste des numéros de borne de contact, là je m’avance, mais je pense que les numéros sont standard relais / contacteur / bloc aux / bloc aux tempo peut importe la marque. Si c’est bien le cas alors ça rend les choses plus faciles, car il suffit d’incrémenter les numéros de contact au fur et à mesure.

*Avoir les numéros de contact et connaître le standard permet aussi de savoir si le nombre de contact liée à un maître est cohérent (actuellement on peut bien avoir 100 contacts esclave sans sourciller). Alors oui cela pourrait sembler secondaire, mais je sais que ce sera demandé un jour donc autant tout bien faire dès le début.
Il y a sûrement des choses que j’oublie mais voila l’idée.

Je peux peut-être sembler pénible mais avec l’expérience je sais que c’est une très grosse erreur de faire un truc qu’à moitié. Je ne compte plus le temps que j’ai perdu et la dette technique à cause de chose qu’on a mal fait et/ou pas très poussé, car on voulait rester simple, puis que j’ai repris car QElectroTech à évoluer et nos/vos exigences aussi.

Pour rebondir sur le sujet du paragraphe avec l’étoile *, avec le peu de vrai schéma que je fais, à chaque fois je me rends compte d’une chose qui manque c’est la possibilité (une fonctionnalité) de vérifier que le schéma est valide c’est-à-dire sans être exhaustif : tous les conducteurs ont un nom, tous les contacts sont liés à un esclave (et donc aussi que le nombre de contact est correct), toutes les bornes sont attribuées à un groupe de bornes, tous les éléments ont un label.
Je suis surpris que personne n’a jamais fait cette demande (ou alors j’ai oublié).

Pfiu quel pavé nomicons/grin

Baboune,
je pense comme galexis car il te faudrait mettre en place une règle pour chaque élément.... j'imagine même pas le boulot que ça représente....
En revanche un truc que l'on pourrais mettre en place (je pense faisable sans trop grande difficulté) c'est de choisir un élément dans ton projet puis de faire un truc du style "appliquer la config à tous les éléments identique" ainsi si tu modifie les textes d'un éléments alors que tu en as déjà posé 30, inutile de te retaper les 30, tu clique sur la fonction et hop réglé.

@Galexis :
Les raccourcis clavier ne doivent pas vraiment poser de problème, par contre je me demande si ce sera bien utilisé ce genre de chose ? Histoire de ne pas coder pour rien.
Dans tous les cas je met ça dans le todo list, et je suis bien motivé pour ajouter ça dans la future version.

baboune wrote:

mais lorsque je dessine des bobines ou des disjoncteurs, la plupart du temps je fais une rangée complète avec le même type de configuration de texte.
Effectivement comme je l'ai dit c'est pas vital. Mais imaginons que la dernière configuration de texte choisie reste active tant que l'on a pas sélectionné une autre.

Oui je pense qu'on est beaucoup à faire comme ça.
Après en te lisant je pense à un truc qui serais vraiment bien et pas nécessairement hyper compliqué, en plus de tout ce qui existe déjà au sujet des textes d'élément.
Lors de l'ajout d'un élément qui a déjà été posé ailleurs dans le projet, c'est appliquer les textes/config du dernier élément en question (basée sur les uuid pour ce qui connaisse un peu le code) pas de sauvegarde rien, juste un truc qui évolue et se complète au fur et à mesure de la création de ton projet. Étant donné qu'il y ai de forte chance que pour un même élément tu lui appliques les mêmes configurations de texte cela devrait fortement accélérer le temps de conception.

Dite moi ce que vous en pensez ? Je pense que cela pourrais être bien d'ajouter ça dans la prochaine version de Qet, après le générateur de bornier bien entendu.

With the link given by Scoprio https://api.kde.org/frameworks/kcoreadd … ackup.html
we can do the backup1 ,2 , 3 etc... files. I add it in the todolist, but don't expect to have it soon, I'm very busy and this feature is not essential.

@tiz
I think you don't understand well.
There are two save in QElectrotech.

1-There is periodic save in QElectrotech and this one write in your file (it's the goal) and so you "lose" work if you have made some change but you don't want to keep it. This feature can be disabled in the properties.

2- There is an automatic and periodic save of the current state of your work (every 2min) but this save is made in another file. I you close QElectroTech this file is deleted. If a crash occur, the next time you open QElectroTech a dialog ask you if you want to restore or not this file. If you click no, the file is not open and is deleted. If you click yes QElectroTech open this file, this is transparent for you and you can continue to work on it (click on save will save in your file)

Bonjour Baboune,
outre le fait de coder la chose il y a quand même un problème car soit
solution 1 : On applique toujours la même configuration pour tous les éléments, mais tu ne veux sûrement pas avoir la même configuration sur tous les types d’élément existant.
Solution 2 : Pour chaque type d’élément définir une configuration, mais là ça demande beaucoup de boulot de ma part et en plus certaine chose dans QElectroTech ne sont pas prêtes pour ça.

Actuellement la meilleure solution pour toi serait de te créer ta collection perso avec les textes déjà mis en place dans l’élément ‘’vierge’’.

1-For the red dot with black dot inside I don't know that exist because we don't use mac macOS. I put it in the todo list.

2-About deleting please open a new subject with more detail.

3-Automatic connection are enable by default, uncheck it.

https://download.qelectrotech.org/qet/m … index.html

First : Probably because the property "one text of potential per folio is check" (see in folio, project and Qet properties)

Second : By default the text of conductor is positioned in the longest segment of the conductor but if you move it manually the text stay in position.

Merci d'avoir pensé à moi pour le FOSDEM, mais effectivement je ne peut pas faire le déplacement pour les raisons que tu évoques…


Au sujet d’Apple, du coup tout ça c’est pour permettre à l’utilisateur de la pomme d’utiliser des logiciels vérifié et exempte de saloperie (pas comme Windows ou l’on peut installer n’importe quoi n’importe comment), mais si le logiciel n’est pas développé par une entreprise ou à minima une asso, c’est tout de suite plus compliqué.

C'est incroyable, apple fait tout sont possible pour faire chier les petits dev comme nous..... et en plus il faut payer.....

Oui j'avais enlevé ça, car j'estimais que les bornes étant un composant générique elles ne devaient pas avoir de propriété établis par défaut. Mais j’ai tort, ça doit être le cas dans la collection officielle, mais pour la collection utilisateur, libre à chacun de faire comme il veut. J’ajoute ça dans le premier post pour ne pas oublier.