plc-user wrote:

Just noticed this warning:

QMetaObject::connectSlotsByName: No matching signal for on_m_color_kpb_changed(QColor)

Fixed this and one other broken signal in current qt6-make - branch!


EDIT:
This signal was already broken in master-branch: Fixed there, too!

127

(23 replies, posted in Code)

@All:
Can someone please explain C/C++-Basics to Re-searcher!

@Re-searcher:

What you are doing is only define a new variable of the type "QPen" with the name "point" and the properties "color=Qt::black" and "penWidth=1"

If it were right what you say, that a variable has different properties, when you use another name:
Call your QPen "Superman" and the grid-points will fly!!!

By declaring and using a new QPen, you totally ignore all other settings, that are made to the QPen in the beginning of the function "Diagram::drawBackground" and use the default-values for Qt::PenStyle, Qt::PenCapStyle and Qt::PenJoinStyle!


Please learn the basic basics of C/C++ for declaring variables, before shouting and yelling:
https://www.learncpp.com/cpp-tutorial/v … alization/

128

(23 replies, posted in Code)

@Re-searcher:

Wenn Du nichts erklärst, kann niemand nachvollziehen, was du meinst!
Ich habe es nicht nötig, hier von irgendwem angeschrieen und beleidigt zu werden und werde nichts mehr zu diesem Thema beitragen!
Nur noch eins: Mit Deiner Aussage zu QPen hast Du Unrecht!

via online-translator:

If you don't explain anything, nobody can understand what you mean!
I don't need to be shouted at and insulted by anyone here and won't say anything more on this subject!
Just one thing: You are wrong with your statement about QPen!

Das ist die laufende Nummer im Projekt oder per Folio.
Je nachdem, was Du eingestellt hast.
Jedenfalls nicht per Präfix!

Kellermorph wrote:

Das hat geklappt.

Schön!

Kellermorph wrote:

Aber wieso der 2 Kategorien braucht weiß ich echt nicht.

Das weiß wohl nur der Geier! 
(Wie das wohl von Online-Übersetzern verarbeitet wird? nomicons/angel)
Wir scheinen da einen Bug gefunden zu haben.
Oder der Programmierer konnte sich seinerzeit nicht vorstellen, daß jemand in der obersten Ebene schon Elemente und nicht nur Verzeichnis-Struktur hat. Wer weiß?

Kellermorph wrote:

Kannst du mir denn noch die Frage mit den Verzeichnissen beantworten? An sich ist das doch kein Problem, wenn irgendwer so ein Pfad kennt oder?

Da war ein gehöriger Schuß Ironie dabei!
Im ersten Schritt geht man erstmal von "komischer" Konfiguration bei der BMK-Formel aus, es kamen aber nur Screenshots von irgendwelchen Verzeichnissen.
Solange der Rechner nicht von außen zugreifbar ist und/oder hinter einer Firewall arbeitet, sollte das kein Problem sein.

Als Versuch:
Lege doch mal die Elemente eine Verzeichnis-Ebene tiefer und passe die qet_labels.xml entsprechend an

Es ist schön, deine Verzeichnisse bald alle zu kennen,  nomicons/wink
aber die entscheidenden Screenshots habe ich noch nicht gesehen:

Die Einstellungen der Nummerierungsregel im Projekt!

In den Elementen ist nur ein leerer dynamischer Text definiert, der als Inhalt das "BMK" (label) zeigen soll.


EDIT: Die Version 0.9 funktioniert auch!

EDIT again:
Die Nummerierungsregeln werden nur angewendet, wenn ein Bauteil neu zum Folio hinzugefügt wird.
Bestehende BMKs werden nicht geändert!

Bei mir sieht das so aus und funktioniert mit der aktuellen QET 0.100-dev - Version.

134

(41 replies, posted in Code)

Based on the qt6-make branch with some more cleanup regarding Qt version checks.

By the way: I have to take a closer look at git-branches. How to use them and so ...  nomicons/wink

No need to hurry: health comes first!

plc-user wrote:

Ich verstehe das so, daß die Datei qet_labels.xml in Dein eigenes Element-Verzeichnis gehört.

Ins Basis-Verzeichnis der Benutzersammlung!
In der Firmensammlung funktioniert das (noch) nicht.

KORREKTUR:
In der Firmensammlung funktioniert das genauso!

Salut Laurent !

On QET download-page for win it says:

Ready-to-use versions are PORTABLE versions: they don't need to be installed!

But when using it, it creates it's configuration in registry ... hmm ...  not really portable!
To be really portable it would be necessary to write the config to a file in sub-dir "conf" in the Ready-To-Use - folder.

Then it would be possible to carry the whole Ready-To-Use - folder to another system and have everything like before. Especially when we think about the near future, when we also ship some fonts with QET.

What do you think, Laurent?
Would it be a big effort to have the configuration in a file for the win Ready-To-Use - version?

138

(41 replies, posted in Code)

plc-user wrote:

Auch, wenn Du den Text als Link markierst und den Text als Ziel-Adresse definieren kannst:
Das Ziel muss auch wissen, daß es Ziel ist, (...)

In the meantime, I have written a code that creates a position list with links and targets in the print module that can be used to insert PDF links.
I just haven't found anything in the Qt docs that explains what a link or a corresponding target should look like so that it works in the PDF file!

***** find positions for PDF-internal links...
XRef from page 3 QPoint(1380,620) to page 4 QPoint(120,440)
XRef from page 3 QPoint(1380,770) to page 4 QPoint(120,90)
XRef from page 3 QPoint(1380,640) to page 4 QPoint(120,420)
XRef from page 3 QPoint(1380,600) to page 4 QPoint(120,400)
XRef from page 3 QPoint(1380,790) to page 4 QPoint(120,110)
XRef from page 4 QPoint(120,90) to page 3 QPoint(1380,770)
XRef from page 4 QPoint(1320,90) to page 5 QPoint(120,90)
XRef from page 4 QPoint(120,110) to page 3 QPoint(1380,790)
XRef from page 4 QPoint(120,440) to page 3 QPoint(1380,620)
XRef from page 4 QPoint(1320,110) to page 5 QPoint(120,110)
XRef from page 4 QPoint(120,400) to page 3 QPoint(1380,600)
XRef from page 4 QPoint(120,420) to page 3 QPoint(1380,640)
XRef from page 5 QPoint(1380,90) to page 6 QPoint(120,90)
XRef from page 5 QPoint(120,90) to page 4 QPoint(1320,90)
XRef from page 5 QPoint(1380,110) to page 6 QPoint(120,110)
XRef from page 5 QPoint(120,110) to page 4 QPoint(1320,110)
XRef from page 6 QPoint(120,110) to page 5 QPoint(1380,110)
XRef from page 6 QPoint(1380,270) to page 8 QPoint(110,180)
XRef from page 6 QPoint(1380,440) to page 8 QPoint(110,440)
XRef from page 6 QPoint(1380,410) to page 8 QPoint(110,410)
XRef from page 6 QPoint(1380,240) to page 8 QPoint(110,210)
XRef from page 6 QPoint(120,90) to page 5 QPoint(1380,90)
XRef from page 8 QPoint(110,440) to page 6 QPoint(1380,440)
XRef from page 8 QPoint(110,180) to page 6 QPoint(1380,270)
XRef from page 8 QPoint(110,410) to page 6 QPoint(1380,410)
XRef from page 8 QPoint(110,210) to page 6 QPoint(1380,240)

There are also additional constraints such as fitting on the page or the print area. "Automagic" zoom factors are used here, which also have to be applied to the positions of the links and targets.

139

(7 replies, posted in Scripts)

Kellermorph wrote:

(...) dass das vorher die falsche Rubrik war (...)

Der andere Thread hat ja mit dem Ansatz angefangen, die PDF-Links direkt in QET zu integrieren, also war das definitiv an der richtigen Stelle!
Wir können dort gerne weiter über PDF-Links innerhalb QET diskutieren, wenn es dazu Ideen gibt:
https://qelectrotech.org/forum/viewtopi … 405#p21405

140

(7 replies, posted in Scripts)

Da waren noch mehr Fragen in meinem Post!

Der Quellcode hat sich also nicht geändert und hier liegt nun eine weitere Kopie einer knapp 70MB großen Datei, die im anderen Beitrag schon angehängt ist?

141

(7 replies, posted in Scripts)

Bin gerade ziemlich verwirrt!

Hat sich der Quellcode geändert?
Wenn ja: Warum liegt der nicht auf github? Da gehört er hin!

Wieso postest Du hier ein knapp 70MB großes AppImage, wenn ein Link auf Deinen github-Account gereicht hätte?
Wieso machst Du einen neuen Thread als Fortführung eines bestehenden Themas auf?

142

(209 replies, posted in Import DXF)

You're already now free to use any font you like, RedBaron!

If you need osifont for your elements and schematics: use it!

BTW: This part of forum is about import of dxf to elements.

Where did you try to find information about this topic so far?
Did you search the forum?

To make it short: Yes!

144

(8 replies, posted in Scripts)

Hallo Xander,

damit wir das alles besser verstehen können:
Vielleicht beschreibst du in ein paar Sätzen, was Du erreichen willst, welche Voraussetzungen im Schaltplan erfüllt sein müssen, etc. pp.

Grafisch ist das schon mal ziemlich beeindruckend!

145

(209 replies, posted in Import DXF)

missing attachment

146

(209 replies, posted in Import DXF)

@vadoola:

As also discussed in the other thread:
We are about to ship a few free fonts with QET. Among them is “osifont” which is often used as a font for CAD applications.
What do you think about specifying “osifont” as a font in converted elements for which no font is specified in the DXF?

When I look at the title block of the well-known “Wet Location Grip” file in LibreCAD and compare the font with “osifont” in QET, the font fits much better than a sans serif font.


Would like to have attached a screenshot, but something's still wrong with forum-settings: I cannot attach a file!

In preparation for the integration of the Liberation fonts in QET, I have updated the element collection.
In doing so, I converted the fonts of the elements to the Liberation substitution as good as possible. Until now there are no elements, which use osifont. The elements have also been tidied up a little.
As long as the fonts are not yet integrated into QET (the PR is still missing), the elements are only available in my github account for the time being.
As soon as the fonts for all systems are available in QET, the elements will be moved to the official collection.
Until then, the elements can be tested by users who have installed the Liberation fonts on their system anyway.
Objective feedback is welcome!


BTW:
It is possible but not needed, to edit the registry directly!
Changing the font-settings in configuration-page will do it for you!

baruse wrote:

cross reference and cable still in my mind, but now it doesn't work

It will be a challenge, to resolve all XRefs!  nomicons/wink

Some words about licenses.

To start with: I am not a lawyer!
If I understand it correctly, the MIT licence is the most permissive; even commercial use is allowed with acknowledgement of the original author.

Hello Baruse!

Very impressing! 
Even as an excited FreeCAD user... nomicons/smile

As I am still planning and writing a code to create wiring-plans from QET-Drawings, I struggle with coming-/ going-references and elements that aren't real parts like jumps and splices:
Does your script handle some of those?
Does your script handle diagrams that have more than one folio and use references?

Please don't feel offended: Just simple questions!

150

(23 replies, posted in Code)

Hallo Re-searcher!

Lass mich auf Deutsch anfangen, Englisch ist weiter unten.

Worin liegt der Unterschied zwischen diesen beiden Code-Fragmenten für "diagram.cpp":

QPen point(Qt::black, 1);
p -> setPen(point);

und

pen.setWidth(settings.value(QStringLiteral("diagrameditor/grid_pointsize"), 1).toInt());

Ich sehe diese Unterschiede:
Im ersten Fragment wird eine hardcodierte "1" als Stiftbreite eingetragen und im zweiten wird eine Stiftbreite aus der Konfigurationsdatei geladen. Ist kein Wert in der Konfigurationsdatei vorhanden, wird eine "1" eingetragen.

Im Ergebnis steht in beiden Fällen eine "1" als Stiftbreite.

Einen Nachteil hat das erste Code-Fragment aber leider: Es wird eine möglicherweise vorgegebene Stiftfarbe hardcodiert durch "Qt::black" ersetzt!


Nun zur Datei "elementview.cpp".

pen.setWidth(5);

und

pen.setWidth(settings.value(QStringLiteral("diagrameditor/grid_pointsize"), 1).toInt());

Im ersten Fall wird die Stiftbreite hardcodiert auf "5" gesetzt und im zweiten Fall auf den Wert aus der Konfigurationsdatei.


p -> drawLine(QLineF(gx - 0.8, gy, gx + 0.8, gy));
p -> drawLine(QLineF(gx, gy - 0.8, gx, gy + 0.8));

und

p -> drawLine(QLineF(gx - (pen.width()/4.0), gy, gx + (pen.width()/4.0), gy));
p -> drawLine(QLineF(gx, gy - (pen.width()/4.0), gx, gy + (pen.width()/4.0)));

Im ersten Fall wird die Linienlänge um von "-0.8" bis "+0.8" definiert und im zweiten Fall auf "Stiftbreite geteilt durch 4".
Für den Fall "Stiftbreite = 5" ist das Ergebnis identisch.

Zusammenfassung:
In einem Fall sind die Stiftbreiten hardcodiert und im zweiten Fall kommt die Stiftbreite aus der Konfigurationsdatei. Bei gleicher Einstellung für die Stiftbreite ist das Ergebnis auf dem Bildschirm das gleiche.
Seit ein paar Tagen ist die Raster-Punktgröße für den Schaltplaneditor und den Element-Editor sogar getrennt einstellbar, sodass man unterschiedliche Werte haben kann: Zum Beispiel "1" für den Schaltplaneditor und "5" für den Element-Editor, wie es in hardcodiertem Code der Fall wäre.

So ist Deine Idee mit anderer Punktgröße für das Raster in den Quellcode von QElectroTech gelangt, Re-searcher!
Die Ergänzung, daß es konfigurierbar ist, kann für die Benutzer nur von Vorteil sein.

Daß Du keine grafischen Artefakte siehst: Freue Dich doch!
Die fallen je nach Pixelgröße des Bildschirms optisch weniger auf!
Du hat einen UHD-Monitor, nicht wahr?

Ich hoffe, dass mit dieser Erklärung deutlich geworden ist, dass es ausdrücklich nicht darum geht, den Code-Vorschlag von jemandem nicht umzusetzen, sondern für uns und die Nutzer von QET eine gute Lösung zu haben!

Beste Grüße
  plc-user


Online-Translator


Hello Re-searcher!

What is the difference between these two code fragments for "diagram.cpp":

QPen point(Qt::black, 1);
p -> setPen(point);

and

pen.setWidth(settings.value(QStringLiteral("diagrameditor/grid_pointsize"), 1).toInt());

I see these differences:
In the first fragment, a hardcoded "1" is entered as the pen width and in the second, a pen width is loaded from the configuration file. If there is no value in the configuration file, a "1" is entered.

The result in both cases is a "1" as the pen width.

Unfortunately, the first code fragment has one disadvantage: a possibly predefined pen color is hardcoded and replaced by "Qt::black"!


Now to the "elementview.cpp" file.

pen.setWidth(5);

and

pen.setWidth(settings.value(QStringLiteral("diagrameditor/grid_pointsize"), 1).toInt());

In the first case, the pen width is hardcoded to "5" and in the second case to the value from the configuration file.


p -> drawLine(QLineF(gx - 0.8, gy, gx + 0.8, gy));
p -> drawLine(QLineF(gx, gy - 0.8, gx, gy + 0.8));

and

p -> drawLine(QLineF(gx - (pen.width()/4.0), gy, gx + (pen.width()/4.0), gy));
p -> drawLine(QLineF(gx, gy - (pen.width()/4.0), gx, gy + (pen.width()/4.0)));

In the first case, the line length is defined from "-0.8" to "+0.8" and in the second case to "pen width divided by 4".
In the case of "pen width == 5" (as in pen.setWidth(5)), the result is identical.


Summary:
In one case the pen widths are hardcoded and in the second case the pen width comes from the configuration file. With the same setting for the pen width, the result on the screen is the same.
Since a few days, the grid point size for the circuit diagram editor and the element editor can even be set separately, so that you can have different values: For example "1" for the schematic editor and "5" for the element editor, as would be the case in hardcoded code.

This is how your idea with a different point size for the grid got into the source code of QElectroTech, Re-searcher!
The addition that it is configurable can only be an advantage for users.

That you don't see any graphical artifacts: Rejoice!
Depending on the pixel size of the screen, they are less noticeable!
You have a UHD monitor, don't you?

I hope that this explanation has made it clear that it is explicitly not about not implementing someone's code proposal, but about having a good solution for us and the users of QET!

Best regards
  plc-user