Salut Laurent!
Thank you for your feedback!
I'll put the missing includes to the sources!
As already said:
I do not get any errors on Debian, ReactOS or Win10 ... strange.
You are not logged in. Please login or register.
QElectroTech → Posts by plc-user
Salut Laurent!
Thank you for your feedback!
I'll put the missing includes to the sources!
As already said:
I do not get any errors on Debian, ReactOS or Win10 ... strange.
Salut Laurent!
I don't get this error on my Debian Unstable.
Maybe there's something missing in helpers.cpp?
Try to add
"#include <string>" or
"#include <sstream>"
at line 30 in helpers.cpp
Salut Laurent !
Je suis heureux d'apprendre que tu es de retour et que tu es sur la voie de la guérison !
Une première version est désormais disponible sur https://github.com/plc-user/QET_ElementScaler, qui tient compte des sauts de ligne pour les éléments "text". De mon point de vue, c'est déjà bien utilisable !
Mais ce qui n'est définitivement pas possible, c'est que le format SVG ne le supporte pas : Le formatage de texte à l'aide d'espaces !
Sans compter qu'il n'est pas de bon ton de formater un texte avec des espaces, plusieurs espaces sont supprimés par le visualiseur SVG (comme en HTML) !
Merci de tester la nouvelle version et de donner votre avis sur les résultats : Je ne peux pas vérifier seul tous les éléments QET (plus de 8000) individuellement ! Seule votre participation permettra d'améliorer le programme !
Cordialement,
plc-user
"Das war Französisch" ... vom Online-Übersetzer
Hallo zusammen!
Auf https://github.com/plc-user/QET_ElementScaler gibt es nun eine erste Version, die bei "text"-Elementen die Zeilenunbrüche beachtet. Aus meiner Sicht ist das schon gut brauchbar!
Was aber definitiv nicht geht, weil das SVG-Format das nicht unterstützt: Formatieren von Text mit Hilfe von Leerzeichen!
Mal ganz davon abgesehen, dass es kein guter Stil ist, Text mit Leerzeichen zu formatieren, werden mehrere Leerzeichen (wie bei HTML auch) vom SVG-Betrachter unterdrückt!
Bitte testet die neue Version und gebt Rückmeldung zu den Ergebnissen: Ich kann nicht allein alle QET-Elemente (mehr als 8000) einzeln überprüfen! Nur durch eure Mitwirkung kann das Programm besser werden!
Gruß
plc-user
und nun noch auf Englisch:
Hello everybody!
There is a first version on https://github.com/plc-user/QET_ElementScaler that recognises line breaks for "text" elements. From my point of view, this is already very useful!
But what definitely doesn't work because the SVG format doesn't support it: Formatting text using spaces!
Quite apart from the fact that it is not good style to format text with spaces, multiple spaces (as with HTML) are suppressed by the SVG viewer!
Please test the new version and give feedback on the results: I cannot check all QET elements (more than 8000) individually! The software can only improve with your cooperation!
Best regards
plc-user
Line-Endings for SVG-Output are implemented now!
Additionally: Line-widths and the dotted and dashed lines were slightly "adjusted".
On https://github.com/plc-user/QET_ElementScaler you find a new pre-release.
In the attachment you see an example: SVG on the left; QET-Element-Editor on the right.
The blue rects in the background show the positions of x-values of the lines and the distances "length1" and "length2" of the Line-Endings.
For me the lines left/right look very similar!
We get closer to a first "non-beta" release.
The next great step will be texts with line-breaks. More on this: later.
Best regards
plc-user
Hello Erik,
as Joshua also explained in this Post (https://qelectrotech.org/forum/viewtopi … 180#p19180) (see above):
In QET we have the CheckBox "closed" for a Polygon. Then the Start- and End-Points of are connected.
In SVG there is no such attribute: There is "Polyline" for "open" and "Polygon" for "closed".
The Element you mentioned has some "open" polygons so that's why a "Polyline" must be used for SVG.
Can you explain, why you think "Polyline" may be wrong or "not good"?
EDIT:
If you think the "kink" in the dashed line is not properly recognizable, then I must refer you to the creator of this element: The drawing is not correct!
These kinks in the dashed lines represent a kind of "notch" for the actuation, which (since I have been working in electrical engineering) is shown with a solid line. Only the notch, not the rest of the mechanical connection of the switching elements! In the attachment you find a screenshot from "Eaton Schaltungsbuch 2023" PDF-Page 485 (https://www.eaton.com/de/de-de/support/ … sbuch.html)
Have we found a volunteer here who wants to fix this error in the elements, Erik?
Hello Erik, (and all others!)
on https://github.com/plc-user/QET_ElementScaler you'll find a new version of QET_ElementScaler in which the handling of line-width and line-style for SVG-output is re-worked.
Here you see an example in the picture (top: SVG, bottom: Element-Editor) and in Element- and SVG-file.
Additionally your example with the re-worked styles is also attached.
I guess I found a quite usable solution...
Please test the new version with your "favorite" elements!
Thanks in advance!
Best regards
plc-user
Hello Erik,
Thanks for Testing, Erik!
The line you are talking about is a dashed polyline and the "missing" part you mention is just a gap in this line.
If you open the SVG-file with a text-editor and change the stroke-dasharray="10,5" to perhaps "7,3" you'll find other parts of the same polyline "missing".
Maybe we need different dash-to-gap-ratio for different line-widths?
Any suggestions?
I'm sure there's much more fine-tuning to be done...
I still can't see what exactly goes wrong!
The DXF-to-Element-converter has nothing to do with the Python terminal plug-in or the TerminalBlock-Generator. These are different applications.
If you have an element-file from DXF-converter that you can edit with QET-Element-Editor, the converter works!
The qet_tb_generator is not necessary to use when converting a dxf to elmt.
Please use the forum-search to find hints on where to download the DXF-converter and how to use it.
Maybe you'll find out that this would be the better place to ask about importing dxf to elmt:
https://qelectrotech.org/forum/viewforum.php?id=12
Good afternoon,
I'm using version 0.9 of QElectroTech ...
Please create a new topic in the suitable forum-area for a new topic!
And do not post the same question in more than one sub-forum.
Hello brutaldeth,
if I understand you correctly, you are looking for a battery charge monitor.
Here is the QElectroTech forum, which is all about drawing electrical schematics...
Best regards
plc-user
Hello claudioro_roberto,
"does not work" or "I can't" is not meaningful enough for us to provide any assistance!
Please be more specific with your question.
And:
Questions and answers regarding QET belong in this forum.
Otherwise other users will not be able to benefit from the discussion!
Best regards
plc-user
Hello Erik,
Thanks for your hints, but I already use the principle of how it should work with the line ends for the terminals.
If you look at the screenshot, you might realise why I'm still hesitating to implement anything: I want it to look at least similar to QET!
The lines in the image all have the same X values for start and end. The actual lines as you see them have different lengths depending on which line-ending is chosen.
Of course, I could also make the lines in the SVG the same length and place the ends over them. But then you can see the line shining through at ends without filling! In the screenshot you see a yellow rectangle behind the lines.
The complexity doesn't get any less if we think of four possible line widths, for which the "real" line length must then of course be adapted to the line width, the line-endings and the values for length...
Salut Laurent!
I'll keep my fingers crossed and wish you all the best!
Health is one of our most valuable goods!
In the meantime I'll try to find out some more things, to implement Line-Markers, etc...
Best regards
plc-user
Hello everybody!
I decided to cancel the project "QET_Element2SVG"!
Instead I added SVG-Output-Support to QET_ElementScaler!
In this context the order of commandline-parameters for QET_ElementScaler had to be adjusted!
So please:
Read the Readme and the scripts and batches provided on the github-page:
https://github.com/plc-user/QET_ElementScaler
In the Release-Section there are binaries for Debian GNU Linux (unstable), ReactOS (32bit) and Win10 (64bit) available, but you should be able to compile the sources on other platforms.
The software is re-written in great parts and may contain errors!
So:
Test the software and report errors, inconsistencies, or simply praise!
Best regards
plc-user
Hallo Achim,
Danke für Deine Erklärung!
Da ich hier kein QT für die Grafik-Konvertierung verwende, am Element nicht verändern möchte und sowieso nur die Element-Datei habe, belasse ich meine Bemühungen mit der horizontalen Ausrichtung von dynamischem Text erstmal so wie sie nun sind, ohne besondere Ausrichtung! Die Positionen passen für mein Auge.
Gruß
plc-user
via Online-Translator:
Hello Achim,
Thanks for your explanation!
Since I don't use QT for graphics-conversion here, don't want to change the element and only have the element file anyway, I'll leave my efforts with the horizontal alignment of dynamic text as they are for now, without special alignment! The positions suit my eye.
Greetings
plc-user
Hello everyone!
For open or closed polygon / polyline I found a solution!
Let's get back to "dynamic_text": Can someone please confirm or explain this:
I have created a test element with three "dynamic_text" and set the horizontal alignment to left, centre or right. I notice that the texts still remain in almost the same X position.
When I apply the attribute left, centre or right to SVG-text, exactly what I expect to happen happens: the reference point of the text is at the specified X position.
That is what I would expect in QET, too...
EDIT:
There is no change in Text-Positions, even when I change Vertical Alignment to Center or Bottom.
Salut Joshua,
I prefer to use plain C++ without special libs that may not be available on other systems, so also here: No QT or so.
It seems that I'm on a good way even with rotated texts!
EDIT:
It seems that the standard-value is true for closed in polygons?
Changed that in my code, because the SVGs looked kind of strange and I could not find any ELMT with "closed=true" in Collection!
Attached you find some screenshots to compare SVG.(top or left) and ELMT (right or bottom)
Salut Joshua!
Thank you for your hints, links and explanations!
I love the sentence: "For historical reasons..."
It always explains, why there are so many ugly workarounds.
But be sure: Most of the software I wrote in the past would NOT look the same if I wrote it now again!
In the moment I think I could make a great step ahead, if I knew how to calculate the bottom-left-corner of the dynamic_text in it's boundingRect.
As you can see in the attached elmt-file I put a dynamic_text at Position x=0, y=5. The boundingRect is positioned exactly there (blue rect). But the text is placed in another position the green rect.
Maybe I find an explanation in QT-documentation from the link how to calculate the "missing values". I have to read.
After that it should be possible to move and rotate the text in SVG to the right position using trigonometry...
Of course you can re-use my code for QET in further versions: That's why we support OpenSourceSoftware!
For now the sources are in a state I would like not to publish. I'll do it later on my GitHub-Account ... promised!
Best regards
plc-user
This is a well known question!
When you have the Information about the internal file-formats of those commercial software, it should be possible to design a converter.
But:
The companies do not publish these internals.
And:
You need to find someone to write that converter in his spare time, if you can't do it yourself!
Salut Laurent!
With your explanations and hints from the older posts: I think we can drop the topic "color" for now. Especially because the translation-table now exists for me and seems to work properly.
As you already mentioned in the other thread, the texts are the particular challenge when converting to SVG!
Not only are the zero points for horizontal text different for "text elements" and "dynamic text", but this has a particular effect when the text is rotated. The font size and rotation-angle must then also be taken into account for the new position. In the attached screenshot you can see at the top the SVG with text and blue rect with the same values for x and y. In the lower part you see Element-Editor with a dynamic text, it's bounding box in dotted line and a rect with the same x- and y-values. In both cases x- and y-values for ELMT and SVG are the same (can be seen with rects)!
The "puzzle" continues if the dynamic texts are aligned differently horizontally and vertically...
Perhaps you have a hint for me where I can read, for example, how the border boxes of the various text elements behave depending on the font size? They are also different in size for text and dynamic text.
The font is a completely different topic: Is it perhaps possible to limit ourselves to a few generic font families instead of trying to support all the fonts that the various systems have to offer? As has already been criticized in many posts here in the forum, the texts behave differently depending on which operating system the file is opened on.
I would therefore suggest that we limit ourselves to generic font families (e.g. SansSerif, Serif, Monospace). Since we can process Unicode, I don't think we need a super-special font that is only available on system xyz. I will at least try to limit myself here for now.
But the most important thing for now would be the positioning of the different texts. Maybe you know where I can read in QET-Sourcecode or QT-Documentation where I can find hints about that?
Best regards
plc-user
Salut Laurent et Joshua,
hello everyone,
based on the Idea of QET_ElementScaler I created a first version of a converting-tool in C++.
Some graphical elements already work very well, like RECT, ELLIPSE. POLYGON, ARC.
Not working: Line-Endings like Bullets or Arrows – they are not defined in SVG and have to be drawn separately.
What is a problem since I've been using Computers and Operating-Systems: Fonts!
So for now only static Texts are basically implemented with limitations: no rotation and the font is saved as "Sans Serif".
Another topic we should discuss are colors. Of course it is very useful for the user to have Names of colors in the GUI. But when I use the given names of the colors in SVG most of them aren't defined and some look different: "green" in QET is much lighter than "green" in SVG. So I had to implement a translation-table from the color-names to RGB-values which work very well in SVG.
Maybe we should use RGB-values instead of color-names in QET-Elements, too? Then the colors would be defined exactly.
And: Do we really need more than 150 named colors in QET where many of them are duplicates like "red"/"HTMLRedRed" or "cyan"/HTMLCyanAqua"/"HTMLCyanCyan" which represent the same RGB-values when I look at the color-table here: https://doc.qt.io/qt-6/qml-color.html?
In the attachments you find a sample-element and the resulting SVG.
I would like to use this thread to discuss the further details of the software with the developers of QET.
Best regards,
plc-user
Hallo Laurent!
Hallo alle anderen!
Ich bewundere Deine Geduld, mit der Du hier regelmäßig die immer gleichen Fragen beantwortest, Laurent! Danke dafür!
Einerseits kann ich es ja verstehen, dass Neulinge bei QET nicht immer auf Anhieb alles finden und auch Schaltsymbole oder Front-Ansichten nicht vorhanden sind. Aber selbst eine Suche in diesem Forum scheint einige Leute schon zu überfordern. Und wenn ich solche Fragen wie "Gibt es auch Hutschienen als Element in QET? Habe ich nicht gefunden!" lese, da schwillt mir schon mal der Kamm: Da hat der Fragende nicht einen Fachbegriff für solch ein Teil als Suchbegriff genutzt: Alleine bei Eingabe von "DIN", "Rail", "Trag", "Schiene" oder "TS35" erscheinen in der Bauteilsammlung Dutzende von Schienen und sonstige Elemente! (Alleine ich habe 36 Varianten von 35mm-Tragschienen bereitgestellt und weitere vorhandene bearbeitet! Nein, ich will dafür keinen besonderen Dank!)
Deswegen ein Appell an Neu-Einsteiger:
Nutzt bitte zuerst die Forum-Suche (https://qelectrotech.org/forum/search.php), bevor ihr eure Frage stellt, die hier vielleicht schon x-mal gefragt und beantwortet wurde. Ja, es ist mit Aufwand verbunden, aber ihr entlastet damit die anderen Teilnehmer – besonders "scorpio810" aka "Laurent", der mit einer Engelsgeduld die immer gleichen Fragen beantwortet!
In anderen Foren werden Fragen gar nicht erst beantwortet, wenn nicht gewisse Spielregeln eingehalten werden.
Da es sich hier um ein mehrsprachiges Forum handelt, versucht bitte auch eine Suche mit englischen und besonders französischen Begriffen: Die Haupt-Entwickler sprechen Französisch! Es ist auch nicht meine Muttersprache, aber dafür gibt es gute Online-Übersetzer, wie z.B. "DeepL.com".
Was mich immer wieder erstaunt, sind auch solche Bemerkungen wie: "In super-teurer Kauf-Software XYZ ist die ganze Bibliothek von Hersteller ABCDE eingebunden, hier gibt es die nicht, ich brauche die aber!"
Da möchte ich gerne antworten: "Ja, die gibt es hier nicht, weil DU uns nicht einmal ein einziges Teil davon zur Verfügung gestellt hast!"
Bei QET handelt es sich um Open-Source-Software, die davon lebt, dass jeder sie benutzen kann.
Aber viel wichtiger ist: Jeder kann selber dazu beitragen, QElectroTech immer besser zu machen!
Wer nicht C++ mit QT programmieren kann, kann vielleicht die Doku in seiner Sprache ergänzen oder anpassen. Andere steuern ihre Bauteilsammlungen bei, oder oder oder! Es gibt so viele Möglichkeiten, dieses Projekt zu unterstützen! QET ist es wert!
Danke für's Lesen!
Gruß
plc-user
via Online-Translator Francais:
Salut Laurent !
Salut à tous les autres !
J'admire la patience avec laquelle tu réponds régulièrement ici aux mêmes questions, Laurent ! Merci pour cela !
D'un côté, je peux comprendre que les nouveaux venus sur QET ne trouvent pas toujours tout du premier coup et que les symboles de commutation ou les vues de face ne soient pas disponibles. Mais même une recherche sur ce forum semble déjà dépasser certaines personnes. Et quand je vois des questions comme "Existe-t-il aussi des profilés chapeau comme élément dans QET ? Je n'ai pas trouvé !", ma crête se gonfle : la personne qui a posé la question n'a pas utilisé un terme technique pour un tel élément comme critère de recherche : Rien qu'en entrant "DIN", "Rail", "Trag", "Rail" ou "TS35", des dizaines de rails et autres éléments apparaissent dans la collection de composants ! (Rien que moi, j'ai mis à disposition 36 variantes de rails porteurs de 35 mm et j'ai modifié d'autres rails existants ! Non, je ne veux pas de remerciements particuliers pour cela !)
C'est pourquoi je lance un appel aux nouveaux venus :
Utilisez d'abord la recherche sur le forum (https://qelectrotech.org/forum/search.php) avant de poser votre question, qui a peut-être déjà été posée et répondue x fois ici. Oui, cela demande un effort, mais vous soulagez ainsi les autres participants - en particulier "scorpio810" aka "Laurent", qui répond avec une patience d'ange aux mêmes questions !
Sur d'autres forums, on ne répond même pas aux questions si certaines règles du jeu ne sont pas respectées.
Comme il s'agit d'un forum multilingue, essayez de faire une recherche avec des termes anglais et surtout français : Les principaux développeurs parlent français ! Ce n'est pas non plus ma langue maternelle, mais il existe de bons traducteurs en ligne, comme par exemple "DeepL.com".
Ce qui m'étonne toujours, ce sont aussi des remarques telles que : "Dans le logiciel XYZ acheté à un prix super élevé, toute la bibliothèque du fabricant ABCDE est intégrée, ici elle n'existe pas, mais j'en ai besoin !"
J'ai envie de répondre : "Oui, elle n'existe pas ici, parce que VOUS ne nous en avez même pas fourni une seule partie !"
QET est un logiciel open source, qui vit du fait que tout le monde peut l'utiliser.
Mais plus important encore : chacun peut contribuer à l'amélioration de QElectroTech !
Ceux qui ne savent pas programmer en C++ avec QT peuvent peut-être compléter ou adapter la documentation dans leur langue. D'autres contribuent avec leurs collections de composants, ou ou ou ! Il y a tellement de possibilités de soutenir ce projet ! QET en vaut la peine !
Merci de l'avoir lu !
Cordialement,
plc-user
via Online-Translator English:
Hello Laurent!
Hello everyone else!
I admire the patience with which you regularly answer the same questions here, Laurent! Thank you for that!
On the one hand, I can understand that newcomers to QET don't always find everything straight away and that there are no circuit symbols or front views. But even a search in this forum seems to overwhelm some people. And when I read questions like "Are DIN rails also available as an element in QET? I haven't found any!", my head starts to swell: the questioner hasn't used a technical term for such a part as a search term: Entering "DIN", "Rail", "Trag", "Schiene" or "TS35" alone brings up dozens of rails and other elements in the component collection! (I alone have provided 36 variants of 35mm DIN rails and edited other existing ones! No, I don't want any special thanks for that!)
Therefore an appeal to newcomers:
Please use the forum search first (https://qelectrotech.org/forum/search.php) before asking your question, which may have been asked and answered here umpteen times already. Yes, it involves a lot of effort, but you'll take the pressure off the other participants - especially "scorpio810" aka "Laurent", who always answers the same questions with the patience of a saint!
In other forums, questions are not even answered if certain rules are not observed.
As this is a multilingual forum, please try searching with English and especially French terms: The main developers speak French! It's not my mother tongue either, but there are good online translators, such as "DeepL.com".
What always amazes me are comments like: "The entire library from the manufacturer ABCDE is integrated in the super-expensive software XYZ, but it's not available here, but I need it!"
I would like to reply: "Yes, it's not here because YOU haven't even made a single part of it available to us!"
QET is open source software that lives from the fact that anyone can use it.
But more importantly, everyone can contribute to making QElectroTech better and better!
If you can't program C++ with QT, you can perhaps supplement or adapt the documentation in your own language. Others can contribute their component collections, or or or or! There are so many ways to support this project! QET is worth it!
Thanks for reading!
Greetings
plc-user
Did you use the Forum-Search before posting here?
"Cross reference", "overlap", etc...
For the second point see this thread:
https://qelectrotech.org/forum/viewtopi … 451#p18451
Schön, dass es dazu eine Lösung auch für bestehende Projekte gibt!
Das Thema ist ja ziemlich regelmäßig hier im Forum zu finden...
Genau dafür ist dieses Forum da:
Sich gegenseitig unterstützen und gemeinsam zur Lösung finden!
QElectroTech → Posts by plc-user
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.022 seconds (31% PHP - 69% DB) with 5 queries