226

(96 replies, posted in Scripts)

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

227

(96 replies, posted in Scripts)

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.

228

(96 replies, posted in Scripts)

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!  nomicons/smile

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)

229

(96 replies, posted in Scripts)

Salut Joshua!

Thank you for your hints, links and explanations!

I love the sentence: "For historical reasons..."  nomicons/cwy
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! nomicons/wink

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... nomicons/cheerful

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!

231

(96 replies, posted in Scripts)

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. nomicons/smile

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

232

(96 replies, posted in Scripts)

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!  nomicons/smile

Zum Ausprobieren mit der Linux-Version, kannst Du das Projekt entweder hier posten, oder falls es nicht für die Augen der Öffentlichkeit sein soll, es mir per PM zukommen zu lassen. Würde dann hier Rückmeldung geben.

Andernfalls kannst Du auch selber versuchen, die DEV-Win-Version "ReadyToUse" zu probieren:
https://download.qelectrotech.org/qet/b … dytouse.7z
Die packst Du in ein beliebiges Verzeichnis (am Besten außerhalb von C:\Programme) auf Deinem Rechner aus und startest es dann über die Batch-Datei "Lancer QET.bat".

Ich benutze auf Win und Linux seit geraumer Zeit nur die DEV-Versionen: Hier gibt es immer die aktuellsten Symbol-Bibliotheken!  nomicons/smile

Die Frage nach der Sprache bezog sich nur auf die Namen der Menü-Einträge. Der Programmcode, der dahintersteckt, ist überall identisch!

Kann Deine Beobachtungen hier nicht nachvollziehen:
Sobald ich die Einstellung ändere, verschiebt sich auf allen Folios der Querverweis an die entsprechende Stelle.

Zur Info meine QET-Version:

QElectroTech V 0.100.0-dev
Compilation: GCC 12.2.0
Built with Qt 5.15.8 - x86_64 - Date : Jun 16 2023 : 01:55:29 
Run with Qt 5.15.8 using 8 thread(s)
CPU : model name : 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz 
RAM Total : 31 GB
RAM Available : 30 GB
GPU : Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01) 
GPU RAM : 
OS : linux - x86_64 - Version : Debian GNU/Linux trixie/sid - Kernel : 6.3.0-1-amd64
*** Qt screens *** 
( 1 : 1920 x 1080 ) 

Komme gerade nicht an ein "Bezahl-System", um das anderwo auszuprobieren...

Gehe davon aus, dass eure Einstellung auch auf deutsch ist:
Menü -> Projekt -> Projekteigenschaften -> Kategorie "neue Folie" -> Reiter "Querverweise"

Wenn ich im DropDown "Position vom Querverweis bei Slave-Bauteilen" z.B. "rechts" auswähle, dann stehen die Querverweise rechts vom BMK, Bei Auswahl von "unten"  steht der Verweis unter dem BMK, usw. ...

Diese Einstellung scheint global zu gelten.

Hallo Thorsten,

wie auch in anderen Threads im Forum schon beschrieben, ist QET nicht auf eine bestimmte Seitengröße ausgelegt. Die Folio-Größe basiert auf den Eigenschaften, die Du unter Folienmaße - Spalten / Zeilen einstellst.

Wie das dann später auf welche Papiergröße gebracht wird, hat primär nichts mit den Folio-Eigenschaften zu tun: Du kannst dasselbe Folio auf verschiedene Papiergrößen ausdrucken. Das hat mit den Druckertreibern zu tun, die Du verwendest.

Wenn Du den PDF-Export von QET verwendest, kannst Du (je nach Betriebssystem) auswählen, auf welche Papiergröße das Folio exportiert werden soll. Bei Windows gibt es systembedingte Einschränkungen, bei Linux ist der entsprechende Button im Export-Fenster aktiv geschaltet.

Zum Schriftfeld:
Das ist immer auf die volle Breite skaliert, egal wie die Anzahl Px in der Vorlage ist. Auch hierzu gibt es bereits Threads hier im Forum.

Vielleicht helfen Dir diese Erklärungen ein wenig weiter...

Please keep in mind, that QET isn't a tool for drawing exact scales on a specific paper size:
Depending on the number of cols and rows per page and the number of px per row/col the exact scale of the drawing is not predictable. The line width must also be considered accordingly: Here it also depends on how the PDF viewer or printer-driver interprets the respective line width. There are already discussions about this in this forum.

For the discussion about scales in QET there are already threads in the forum. One of the latest:
https://qelectrotech.org/forum/viewtopic.php?id=1924

Do you mean something like this?

@Olaf:
Es sieht für mich so aus, dass "nur" die deutschen Übersetzungen fehlen und deshalb die Bauteil-Bezeichnung im Suchbaum erscheint, die in der jeweiligen Element-Datei als erstes aufgeführt ist. Für einzelne Elemente und "qet_directory"-Dateien habe ich nun die (mir fachfremden) deutschen Begriffe eingetragen und bei github einen Pull-Request erstellt.
Das gesamte QET-Projekt lebt aber davon, dass sich viele Leute daran aktiv beteiligen! Vielleicht kannst Du Dich an der Stelle hier einbringen und die deutschen Übersetzungen für den Sanitär-/Heizungsbereich ergänzen?
Dafür brauchst Du nur die Datei in einem Text-Editor (Notepad++, Kate, etc. je nach verwendetem System) laden und eine Zeile für Deutsch ergänzen. Probier's aus: Ist gar nicht so schwer!  nomicons/smile
Wie wir die Übersetzungen dann für alle nutzber machen, sehen wir dann im nächsten Schritt!  nomicons/wink
Andere Nutzer wären Dir dankbar!

Hallo Peter,
Salut Laurent!

Der Ausschnitt aus der "Readme" ist genau eine Zeile zu kurz für dieses "Problem":
Das Programm erkennt "ab.elmt" nicht als Dateinamen, deswegen die Fehlermeldung

file "NoFileNameSet.elmt" could not be loaded: File was not found

Wenn für beide Richtungen ein Faktor angegeben werden soll, muss der Dateiname mit "-f" angegeben werden. Siehe Readme.md:

QET_ElementScaler [options] [-x FactorForX] [-y FactorForY] -f FILENAME

das ergibt eine Datei mit zusätzlichem ".SCALED" im Dateinamen. Für Dein Beispiel:

QET_ElementScaler -x 2 -y 3 -f ab.elmt

Soll das skalierte Element einen eigenen Dateinamen bekommen, sieht der Aufruf für Deine Beispiel-Dateien so aus:

QET_ElementScaler -x 2 -y 3 -f ab.elmt -o > cd.elmt

Insagesamt sehen die Aufrufe und Ergebnisse auf meinem Linux-System so aus:

ich@tutnix:/tmp$ ./QET_ElementScaler -x 2 -y 3 -f ab.elmt
ich@laptop:/tmp$ ls -l
insgesamt 384
-rw-r--r-- 1 ich ich  13531 28. Dez 13:50 ab.elmt
-rw-r--r-- 1 ich ich  14453 19. Feb 08:39 ab.SCALED.elmt
-rwxr-xr-x 1 ich ich 357064 25. Jan 20:16 QET_ElementScaler
ich@laptop:/tmp$ ./QET_ElementScaler -x 2 -y 3 -f ab.elmt -o > cd.elmt
ich@laptop:/tmp$ ls -l
insgesamt 400
-rw-r--r-- 1 ich ich  13531 28. Dez 13:50 ab.elmt
-rw-r--r-- 1 ich ich  14453 19. Feb 08:39 ab.SCALED.elmt
-rw-r--r-- 1 ich ich  14453 19. Feb 08:51 cd.elmt
-rwxr-xr-x 1 ich ich 357064 25. Jan 20:16 QET_ElementScaler
ich@laptop:/tmp$

Moin Olli,

einfache Antwort: Nein.

For debugging it is always helpful for the programmer to know the software-version, the operating system and the version of it...

247

(17 replies, posted in Elements)

For QET_ElementScaler I now use this (mathematically correct) determination for the min-max values of an elliptical arc:

    // calculate points on ellipse-circumference:
    // x = a ⋅ cos(t)
    // y = b ⋅ sin(t)
    // with t = 0 .. 2*pi = ([0 .. 360]/360)*2*pi
    // for ARC with x- and y-offset in a loop from Start to (Start+Angle):
    for (int i = Start; i <= (Start + Angle); i++){
        double val_x = X + (Width/2) * (1 + cos((i%360)/360.0*2*pi));
        double val_y = Y + (Height/2) * (1 - sin((i%360)/360.0*2*pi));
        XYMinMax.add(val_x, val_y);
    }

This may be too time-consuming for the productive version of QET, but here I allowed that "luxury-version"...   nomicons/wink
Now available here: https://github.com/plc-user/QET_ElementScaler

248

(17 replies, posted in Elements)

Yes, I think you are right, Laurent!
In the function starting here:
https://github.com/qelectrotech/qelectr … y.cpp#L189
The ELSE branches ensure that only the start and end points of the ARC are used for the calculation of the surrounding RECT size. In this case, this is counterproductive!

Is there anything against always assuming an "ellipse" for the determination of the surrounding rectangle?
(But please don't expect me to adopt this today: Before I have managed to get familiar with QT-programming and the IDE it will be Christmas again... nomicons/wink)

Another thought for ARCs:

For the determination of the surrounding rectangle, it might be easier to limit the number of case distinctions. For this it might be helpful if (at the latest when saving the XML file) we always keep the angles of the ARC in the positive range?
These arcs are identical:

Start = -10 / Angle =  30
Start =  20 / Angle = -30
Start = 350 / Angle =  30

For case distinctions in internal calculations, however, it might help...

Implemented normalisation for start and angle of ARCs in QET_ElementScaler and just released a new version on github.
Maybe it helps...

249

(17 replies, posted in Elements)

Maybe here?

https://github.com/qelectrotech/qelectr … c.cpp#L165

/**
 * @brief PartArc::sceneGeometricRect
 * @return the minimum,
 * margin-less rectangle this part can fit into in scene coordinates.
 * It is different from boundingRect() because it is not supposed
 * to imply any margin,
 * and it is different from shape because it is a regular
 * rectangle, not a complex shape.
 */
QRectF PartArc::sceneGeometricRect() const
{
    return mapToScene(QetGraphicsHandlerUtility::rectForArc(m_rect, m_start_angle/16, m_span_angle/16)).boundingRect();
}

... or at least in that file?

250

(17 replies, posted in Elements)

I use the same code in QET_ElementScaler:

    // calculation taken from QET-sources:
    int upwidth = ((width/10)*10)+10;
    if ((width%10) > 6) upwidth+=10;

    int upheight = ((height/10)*10)+10;
    if ((height%10) > 6) upheight+=10;

Just a thought, Laurent:
Can it be that ARCs aren't taken into account for calculating Element's size?
The other graphical elements seem to be used for calculating size...