Search options (Page 16 of 27)

@Laurent: +2

o.k.  –  Merci, Laurent !

In this case, the learning curve is not quite so steep for me: I "only" have to dive deeper into QT and QET programming!
I've hardly ever had anything to do with sqlite as a programmer.

As I said: For now I just want to understand how QET works "under the hood"... and maybe contribute some things.

"Still learning!" (even at my age )

Na ja ... "unnötige Drückerei" ... kommt ja immer darauf an, was Du machen willst!

Wenn Du einmal ein Potenzial und die zugehörigen Leitereigenschaften definiert hast und an das Potenzial einen weiteren Draht anschließen willst, macht es schon Sinn, die Eigenschaften überall gleich zu haben:
Potenzial definiert -> neuen Draht dazu -> Eigenschaften vom neuen Draht passen!

Wieso sollte sich zwischendurch Leiterfarbe oder Querschnitt ändern, oder das Potenzial einen anderen Namen bekommen?
An ein Potenzial gehört eine Farbe, ein Querschnitt, etc. pp.
Wenn zwischendrin z.B. eine Steckverbindung ist, kann ich mir das noch vorstellen...
Aber vor und hinter einem Schalter oder einer Sicherung ist definitiv nicht dasselbe Potenzial, also müssen die Eigenschaften neu eingestellt werden!

Gib' doch mal deinen Anwendungsfall preis, bei dem unterschiedliche Leitereigenschaften für ein Potenzial Verwendung finden sollen (musst ja keine Geheimnisse verraten!).

When we insert empty tags it makes the number of changed code-lines even smaller! 

Here's the new diff:

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..272720382 100644
--- a/sources/qetgraphicsitem/terminal.cpp
+++ b/sources/qetgraphicsitem/terminal.cpp
@@ -744,6 +744,11 @@ QUuid Terminal::uuid() const
        return d->m_uuid;
 }
 
+QString Terminal::name() const
+{
+       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;

The TerminalNames are only inserted into the connection, when the terminals have UUIDs ... only then!

In the element-collection I found "some" elements which have terminals with names but no UUID. Already working on them...

You are right: The element-editor could be much more comfortable!
But at the moment ...

Do you know that you can move parts with smaller steps when pressing <Ctrl>?
For moving at even smaller steps: use the Input-Fields / SpinEdits

All kinds of geometrical forms (triangle, rectangle,...) can be drawn with the polygon-tool. And you can edit every node of the polygon afterwards.

"closed lines" => polygons  ?

Just a suggestion:
https://qelectrotech.org/forum/viewtopic.php?id=2716

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.

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. 

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

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

cross-platform with DoubleCommander's search function!

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!