Search options (Page 1 of 33)

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

Damn
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

It's not a bug it's a feature .
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

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.

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

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 )

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 .

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

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é

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

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)

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

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