Hello everyone!

For some time now, it is possible to assign a name to terminals in the element files. A unique UUID is automatically added in the background. If such a component is then inserted into a schematic and provided with connections, the UUIDs of the terminals are already used in the qet file to identify the connection.

At some point in the future, when the developers have (a lot of) time for the project again, the "UUID" and "Name" information will be used to automatically generate cable plans and wiring instructions.

As a "programming exercise", I looked in the source code for a way to include the names of the terminals in the connection line in the schematic file and actually found what I was looking for!

However, there is one "difficulty":
What name may automatically be used if the creator of the element has not assigned any names?
I made it easy for myself here and also saved the UUID of the connection for the name.

Here is the resulting diff file:

diff --git a/sources/qetgraphicsitem/conductor.cpp b/sources/qetgraphicsitem/conductor.cpp
diff --git a/sources/qetgraphicsitem/conductor.cpp b/sources/qetgraphicsitem/conductor.cpp
index dc9d23595..df0e9fdc6 100644
--- a/sources/qetgraphicsitem/conductor.cpp
+++ b/sources/qetgraphicsitem/conductor.cpp
@@ -1048,6 +1048,7 @@ QDomElement Conductor::toXml(QDomDocument &dom_document,
        } else {
                dom_element.setAttribute("element1", terminal1->parentElement()->uuid().toString());
                dom_element.setAttribute("terminal1", terminal1->uuid().toString());
+               dom_element.setAttribute("terminalname1", terminal1->name());
        }

        if (terminal2->uuid().isNull()) {
@@ -1056,6 +1057,7 @@ QDomElement Conductor::toXml(QDomDocument &dom_document,
        } else {
                dom_element.setAttribute("element2", terminal2->parentElement()->uuid().toString());
                dom_element.setAttribute("terminal2", terminal2->uuid().toString());
+               dom_element.setAttribute("terminalname2", terminal2->name());
        }
        dom_element.setAttribute("freezeLabel", m_freeze_label? "true" : "false");

diff --git a/sources/qetgraphicsitem/terminal.cpp b/sources/qetgraphicsitem/terminal.cpp
index 54f9ece5f..951d67aa0 100644
--- a/sources/qetgraphicsitem/terminal.cpp
+++ b/sources/qetgraphicsitem/terminal.cpp
@@ -744,6 +744,16 @@ QUuid Terminal::uuid() const
        return d->m_uuid;
 }

+QString Terminal::name() const
+{
+    if (d->m_name == "")
+    {
+               return ((d->m_uuid).toString());
+       } else {
+               return d->m_name;
+       }
+}
+
 /**
        @brief Conductor::relatedPotentialTerminal
        Return terminal at the same potential from the same
diff --git a/sources/qetgraphicsitem/terminal.h b/sources/qetgraphicsitem/terminal.h
index e014d2a1f..a8d22abc8 100644
--- a/sources/qetgraphicsitem/terminal.h
+++ b/sources/qetgraphicsitem/terminal.h
@@ -74,6 +74,7 @@ class Terminal : public QGraphicsObject
                Diagram  *diagram             () const;
                Element  *parentElement       () const;
                QUuid uuid                    () const;
+               QString   name                () const;

                QList<Conductor *> conductors() const;
                Qet::Orientation orientation() const;

I understand this code fragment explicitly as a basis for discussion:
Please have a look at it and leave comments!

Best regards
  plc-user

Hallo Stefan,

für konkrete Hilfe zum Aufsetzen eines Build-Systems wäre es hilfreich zu wissen, auf welchem System Du QET (mit-)entwickeln willst.

Da ich normalerweise ein sehr schlankes Xfce4 auf Debian unstable nutze, wollte ich das an dieser Stelle "sauber" getrennt halten und habe deswegen eine separate VM mit Debian stable mit LXQT als Fenstermanager aufgesetzt. Da ist dann schon eine ordentliche QT-Umgebung vorhanden, in die sich qtcreator und die anderen Pakete "schlanker" einfügen lassen als bei einer GTK-Umgebung.
Trotz des "Zusatzaufwandes" der VM war das insgesamt recht überschaubar, bis dann erstmalig das Kompilieren von QET geklappt hat. nomicons/smile

Das Klemmenplan-Plugin oder der Klemmleisten-Manager deckt auch die Verbindungen zwischen Bauteilen ab?
Ich glaube das ist der Anwendungsfall, den Stefan für die Produktion beschreibt...

Um einen eindeutige Verdrahtungsvorschrift zu erstellen, muss aus dem Schaltplan natürlich auch eindeutig hervorgehen, welcher Draht von wo nach wo gezogen werden sollI

Im Bild (Anhang) siehst Du die Schwierigkeit:
Im oberen Teil ist nicht ersichtlich, welche Verbindung von wo nach wo geht. Jedenfalls nicht auf den ersten Blick.
Für die eindeutige Verdrahtungsvorschrift müssten die Verbindungen, wie im unteren Teil zu sehen, mit Abzweigen erstellt werden. Dann kann man sehen, wie die Leitungsführung ist. Das solte im Idealfall automatisch vom Schaltplan-Editor erledigt werden und nicht wie hier mit den Elementen "Abzweig".

An den vielen "müßte" und "sollte" kannst Du vielleicht ablesen, dass diese Funktion so noch nicht vorhanden ist.

Du wirst also wahrscheinlich selber etwas "stricken" müssen, das sich durch die conductor-Einträge der qet-Datei hangelt und mit den UUIDs der Bauteile und Anschlüsse die Verdrahtung herauspuzzelt. Bedingung für eine "saubere" Verdrahtungsvorschrift ist aber auch die persönliche Disziplin des Schaltplan-Erstellers, die Verbindungen so zu ziehen, wie es später verdrahtet werden soll.  nomicons/wink

Hallo Stefan,

So wie ich das sehe, wird das schwierig ... zumindest im Moment.

Ja, bei den Anschlüssen der Elemente sind bei neueren Dateiversionen Namen und UUIDs vorhanden. Die UUIDs werden beim Erstellen des Elements automatisch vergeben, aber für die Eingabe der Namen ist der Ersteller des Elements verantwortlich.
Von daher hast Du es auf jeden Fall (bei Benutzen von vorhandenen Elementen) nicht leicht, die herauszufinden, wo Namen und UUIDs vorhanden sind.
Zusätzlich:
Die Eigenschaften "Name" und "UUID" bei den Anschlüssen mögen zwar bei den von dir benutzten Elementen vorhanden sein, aber soweit ich das verstehe, sind diese Angaben im Moment noch "for future use"!  nomicons/sad
Joshua (der Haupt-Entwickler von QET) hat diese Eigenschaften vor einiger Zeit für die Elemente eingeführt, die werden aber im Schaltplan-Modul noch nicht weiter verwendet. Ich habe zum Testen einfach mal zwei Bauteile, von denen ich weiß, dass sie Namen und UUIDs haben, miteinander in einem Plan verbunden, finde aber in der *.qet-Datei keinen Hinweis darauf, dass die Klemmstellen irgendetwas miteinander zu tun haben.
Leider haben die beiden Entwickler von QET im Moment aus persönlichen Gründen wenig Gelegenheit, aktiv an QET zu entwickeln, sodass wahrscheinlich noch Zeit ins Land geht, bevor die Namen der Anschlüsse im Schaltplan Verwendung finden ... leider!
Es sei denn, Du kennst jemanden, der die Entwickler aktiv unterstützen kann!  nomicons/wink
(Das gilt selbstredend auch für die anderen Leser!)

The menu a good place to try out whether setting of transparency works in principle! But the developer must have had something else in mind for this menu item than the SVG export...
For this function a new Checkbox in the export-dialog should be introduced.

Maybe with the sourcecode I uploaded to my github-repository?
https://github.com/plc-user/qelectrotech-source-mirror
(can create a pull-request...)

EDITED this post and removed the diff from here because it grew bigger and bigger...  nomicons/wink

EDITED AGAIN:
Setting and function is already available in Version 0.100 (DEV)  nomicons/smile

Vielleicht meinst Du dies:

"Parent" = Master-Element
"Child" = Slave-Element

Die Elemente müssen natürlich entsprechend angelegt sein, dann kannst Du ein oder mehrere Slaves einem Master zuordnen, die dann auch die Bezeichnung vom Master bekommen.

scorpio810 wrote:

Personally, I wouldn't calculate a script for so little. With KDE's Kate editor, you can search and replace one occurrence by another in all the files in a folder or in sub folders in 3 seconds.

cross-platform with DoubleCommander's search function!

Hello Tom,

as far as I can see:
All graphical elements of the diagram are completely processed by a QT library function. So if you want to change the background color of the SVG export, you have to change the background color of the folio. This is not possible at the moment.
Due to the small number of active developers, I see little chance of this being implemented in the foreseeable future.

Best regards
  plc-user

135

(96 replies, posted in Scripts)

It seems that Pixel-Graphic-Software doesn't show the SVG right.
Gwenview and KolourPaint are originally made for Pixel-Graphics?

LibreOffice Draw and Firefox show the SVGs correctly!

136

(96 replies, posted in Scripts)

Salut Laurent!

Done!  nomicons/smile

137

(96 replies, posted in Scripts)

Hello Lieven,

I guess you mix two different topics:
This thread is about a commandline-tool to convert QET-Elements to SVG.
The screenshot you sent is about export of QET-Schematics.
These are different topics. You should open a new thread in the English Forum...

But to answer your question:
M$-Office would not be my first choice when it comes to dealing with SVG-Graphics!
In my opinion it would be the last choice: only if nothing useful is available, but that's another point...  nomicons/wink

You are right:
When I export a QET-Schematic to SVG there is much free space right and below of the schematic!
It seems that the picture-size in the SVG-file isn't set correctly. Export to PNG shows the correct view!
So if you want to use the export in a word-processor then maybe PNG-export would be better...
Or you edit the SVG with Inkscape before importing to office: Here you can set the document-size to the contents
(Menu -> Document-Settings -> Button... see attachment)

EDIT:
From whatever reason the width and height of the SVG is calculated too big!
I tried some different folio-sizes and exported them to SVG: It seems to be a constant factor of 16/9 = 1.7777777

With this patch all exported SVGs had the correct width and height:

diff --git a/sources/exportdialog.cpp b/sources/exportdialog.cpp
index a50c5147e..6588ecbc3 100644
--- a/sources/exportdialog.cpp
+++ b/sources/exportdialog.cpp
@@ -411,7 +411,7 @@ void ExportDialog::generateSvg(
        
        // "joue" la QPicture sur un QSvgGenerator
        QSvgGenerator svg_engine;
-       svg_engine.setSize(QSize(width, height));
+       svg_engine.setSize(QSize((width*9/16), (height*9/16)));
        svg_engine.setOutputDevice(&io_device);
        QPainter svg_painter(&svg_engine);
        picture.play(&svg_painter);

@Laurent and/or @Joshua:
Maybe one of you can check?

In the attachment you find a package with two SVGs:
one exported from original QET-Version and the other exported from my local QET-version with 9-16-patch

Best regards
  plc-user

138

(96 replies, posted in Scripts)

Salut Laurent,

as far as I understand this code fragment, this is the workaround for the font size of the old "input"-elements. I think that this code-fragment has become obsolete with my inserted part.
In my local QET version with which I opened and saved the ~4500 elements, this part of code was also active. It didn't do any harm!
But Joshua will know exactly!

Best regards,
  plc-user

If the slave-element is defined to have "switch state" defined as "other" then there is no reference shown with the master!

140

(96 replies, posted in Scripts)

Salut Laurent!

In my opinion it's not a "must have", if we think about users who only need the official collection.
When we think about QET's long-standing users, that have elements created with earlier versions of QET with "input"-Elements inside, we should apply the patch.

Best regards
  plc-user

Hello jari!

There is something wrong with your <shift> - key!  nomicons/wink

Please use Forum-Search to find answers to your questions:
References in PDFs and import/export to/from CSV are asked very often...

Best regards
  plc-user

Hallo Fabian,

Wahrscheinlich wirst Du um eine SQL-Abfrage nicht herumkommen.

Probiere doch mal die Forumsuche mit den Stichwörtern "Export" und "BOM":
Da kommt ein Ergebnis zu 'nem französischen Beitrag, wo der Frager zum Schluß sehr zufrieden war.

Hallo Thorsten,

es geht ja hier nicht darum, irgendwelche Verweise zu machen. Das Verweis-Element bietet nur die Möglichkeit, die gewünschten Informationen anzuzeigen. Im Anhang ein Beispiel, wie das aussehen kann.

-----------

This is not about making any references. The link element only offers the option of displaying the desired information. Attached is an example of how this can look.

144

(96 replies, posted in Scripts)

This is getting more and more interesting: Another ~500 views on this topic and still no feedback that one or the other element doesn't work.
It's not that I'm looking for special thanks or fishing for compliments: I asked for "proofreaders".
You didn't want it any other way: I will "release" the pull request with the changed elements after all.

As said before: To say nothing is to agree!

Best regards
  plc-user

Hallo Thorsten,

versuche doch mal eine Forum-Suche mit dem englischen Begriff für "Leiterquerschnitt": gauge

Vor nicht allzulanger Zeit kam dieselbe Frage schon mal auf und darauf hat Laurent geantwortet.

Gruß
  plc-user


PS:
Mit deutsch bist Du im englischen Sub-Forum irgendwo falsch abgebogen...  nomicons/wink

Hallo Andi,

andi11 wrote:

thank's very much.
i thought that it's drawn wie QET elements out of the library. But you used just basic lines and stuff like that, clever solution.
Is there a way to draw it with conductors? That way i should have an place to keep metadata, like purpose of signal.

irgendjemand muss mit einem Element anfangen:
Vielleicht ist dies ja der Anfang von einem großen BUS-Unterverzeichnis?  nomicons/wink

Gruß
  plc-user

147

(96 replies, posted in Scripts)

Hello everybody!

In this post https://qelectrotech.org/forum/viewtopi … 380#p19380 I asked the forum participants to try out the elements they use most often and give feedback on whether they are OK.
After eight weeks of waiting, I am a little surprised:
There was no feedback on the elements!

That can mean two things:
No one has checked them or there is nothing wrong with them.

In German, we have a saying:
To say nothing is to agree!

So I'll just say that the elements that I automatically updated to the current version are fine! Nevertheless, I will not release the pull-request myself:
The "four-eyes principle" should still be applied in my opinion.

Best regards
  plc-user

Für den Klemmleisten-Manager hat Laurent ja schon ein paar Anleitungen verlinkt.

Vielleicht bist Du für Fragen zum Python-Plugin hier besser aufgehoben?
https://qelectrotech.org/forum/viewforum.php?id=16

Kann es sein, dass da zwei verschiedene Möglichkeiten, Klemmleisten zu bearbeiten durcheinandergewürfelt werden?

Es gibt einmal das Python-Plug-In, das separat installiert werden muss und über

Menü - Projekt - Klemmenplan-Plugin starten

gestartet wird und seit einiger Zeit einen von Joshua selbst entwickelten QET-internen Klemmleisten-Manager

Menü - Projekt - Klemmleisten-Manager (DEV)

(zumindest in der 0.10 Dev-Version)

HTH

SchindiSoft wrote:

Man könnte anstatt Ort natürlich auch eine andere dynamische vordefinierte Information / Funktion verwenden - Bauteil einfach nach Wunsch anpassen - is ja nicht verboten

Nützt nur nix, wenn die Software den XML-tag, den ich händisch einfüge, nicht kennt!

Ein Bauteil, das als "Klemme" definiert ist, hat keine Eigenschaft "Ort"!
Habe ich im Post von FH völlig überlesen, dass es sich um eine Klemme handelt, der er einen Ort zuweisen wollte!