Search options (Page 1 of 33)

Whaou super boulot.
Quand je vois ça, ça me rappelle à quel point qelectrotech doit être remanier en profondeur (ce que je dit depuis longtemps...) et particulièrement le format de fichier ainsi que la base de donné interne (sqlite) qui deviendrais un élément fondamental de Qet et permettrais à des gens comme vous de proposé et d'integrer plus facilement des addons pour Qet.
Bonne continuation.

Übersetzung Deutsch

Wow, super Arbeit.
Wenn ich das sehe, wird mir wieder bewusst, wie sehr qelectrotech grundlegend überarbeitet werden muss (was ich schon seit langem sage ...), insbesondere das Dateiformat und die interne Datenbank (sqlite), die zu einem grundlegenden Bestandteil von Qet werden und es Leuten wie Ihnen ermöglichen würden, Add-ons für Qet einfacher vorzuschlagen und zu integrieren.
Viel Erfolg weiterhin.

Point numéro 1 :
Pour déplacer un texte il cliquer dessus en maintenant la touche maj afin de pouvoir le glissé avec la souris.
Point numéro 2 :
Dans le panneau latéral des propriétés d'élément tu peut gérer l'alignement du texte.
Point numéro 3 :
Allé dans les propriétés du conducteur.
Point numéro 4 :
Le gestionnaire de bornier est une fonctionnalité en cours de développement (d’où le (DEV) dans le menu), celui-ci est présent à titre d'essais pour les utilisateurs mais ne doit pas être utilisé en prod (ou à vos risque et péril)

Lors d'un copié coller toutes les liaisons sont supprimé, même si tu copie-colle un élément maître et sont esclave.
Pour le nom des éléments c'est paramétrable dans les propriété de Qet.

n'hésite pas à consulter la doc en ligne (Aide -> Manuel en ligne ou tout simplement F1) celle-ci n'est pas à jour mais couvre quand même une bonne partie de Qet.
J'en profite pour préciser que nous somme toujours à la recherche de contributeur, dont entre autre pour compléter/mettre à jours de la documentation.

FRENCH

Pour aller plus loin encore, on bute ici sur une des grosses dette technique (mes dettes…) de QElectroTech.
Pour faire rapide, au fur et à mesure de l’évolution de QET j’ai recréé la roue au niveau des formats de fichier (à cause de ma méconnaissance). L’une des 1000 choses auquel je pense au sujet de QET c’est de reprendre totalement le format de fichier des éléments afin que ceux-ci soit de vrai svg (ou plutôt une balise svg à l’intérieur du xml décrivant tout l’aspect graphique dont les textes statique).
Bon tout cela ne change rien au problème et un warning lors de l’ouverture devrais être suffisant, mais si il faut coder une moulinette il serais intéressant de voir si on peut se rapprocher un peu du svg,
Pour info j’ai déjà ajouter quelque fonction dans le code qui écrit du vrai svg afin de préparer le terrain.

Pour en revenir à Qt5 et Qt6 il était question de faire la release de la 0.100 sous Qt6, mais au vue des divers problème je pense qu’il est plus que raisonnable de faire une release en Qt5 et une fois tout les problèmes réglé causé par Qt6 faire une nouvelle release sous Qt6 même si c’elle-ci n’apporte aucune nouvelle fonctionnalité.

ENGLISH

To go even further, we come up against one of QElectroTech's major technical debts (my debts...).
To cut a long story short, as QET evolved, I reinvented the wheel in terms of file formats (due to my lack of knowledge). One of the 1,000 things I think about with regard to QET is completely revamping the file format of the elements so that they are true SVG (or rather an SVG tag within the XML describing all the graphics, including static text).
Well, none of this changes the problem, and a warning when opening should be sufficient, but if we have to code a converter, it would be interesting to see if we can get a little closer to SVG.
For your information, I have already added some functions to the code that writes true SVG in order to prepare the ground.

Coming back to Qt5 and Qt6, there was talk of releasing 0.100 under Qt6, but given the various problems, I think it's more than reasonable to release under Qt5 and, once all the problems caused by Qt6 have been resolved, release a new version under Qt6, even if it doesn't bring any new features.

I think a New version would bé nice. I need to fix some minor thing ( I don't like how parts are rotated in the éléments editor, around the 0,0 coordinate instead of a point of the curent sélection)

Actually the terminal strip feature is in heavy devellopment. This is why some thing are not saved, and a lot of other thing are not finished / started about this feature.

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)

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 .