That would mean, we only remove empty entries with element-information in element-files, but keep all other properties with empty content.

I would like to remove empty entries in elementInformation from element-files, because it would be a massive overhead and useless information, if an element like an ordinary terminal would have the empty information about up to four auxiliary parts...

Already prepared this diff:

diff --git a/sources/diagramcontext.cpp b/sources/diagramcontext.cpp
index 864ad9b3a..681fed49e 100644
--- a/sources/diagramcontext.cpp
+++ b/sources/diagramcontext.cpp
@@ -151,7 +151,10 @@ bool DiagramContext::operator!=(const DiagramContext &dc) const
 void DiagramContext::toXml(QDomElement &e, const QString &tag_name) const
 {
        foreach (QString key, keys()) {
-               if (m_content[key].toString().trimmed().isEmpty()) { continue; }
+               if ((tag_name == "elementInformation") &&
+                       (m_content[key].toString().trimmed().isEmpty())) {
+                       continue;
+               }
                QDomElement property = e.ownerDocument().createElement(tag_name);
                // try to sort attributes by removing and re-adding
                property.removeAttribute("show");

What do you think, Galexis and Laurent?

O.k. ... guess I found what you mean.
Is it about such entries in project-file?

    <properties>
        <property name="creator" show="1"></property>
        <property name="plant" show="1"></property>
        <property name="author" show="1"></property>
        <property name="folio" show="1"></property>
        (...)

That piece of code changed in the commit is used more than once:
Not just for element-information but also for properties in project-file.

Guess what you mean:
These entries can be used in a "template" for use with new projects.

Then we could differentiate:
- do not save empty information in elements (these are fixed in sourcecode)
- keep property-entries in project-files (entries can be added during runtime)

What do you think?

galexis wrote:

(...) les variables de projet qui n'ont pas de valeur ou un espace en valeur disparaissent après avoir enregistré, puis réouvert le projet.

To avoid misunderstandings:

What do you mean with "variables de projet"?

Maybe the following?

In this commit there was a change with element-information:
In the entries leading and trailing whitespace is removed from content and entries without content are not saved anymore. Why should we save overhead without additional information?

Salut Laurent !

The limitations for maximum image sizes do not have to be set from image-type specifications, but from limitations in QPainter!

Cite from Qt-docs:

(...) while coordinates greater than +/- 2^15 can be used, any painting performed with coordinates outside this range is not guaranteed to be shown (...)

That is true: images greater than 32767 show a black margin! 

That's why we need to set the maximum width and height of exports to pixel-images to 32767.
Sorry for inconvenience!
Already prepare a PR ... follows soon!

Salut Laurent !

According to the research you did (Thanks for that!), there are limitations of the dimensions

32767 x 32767 for BMP
65535 x 65535 for JPG

With these infos I added some code to set the limits according to the file-type, but kept the maximum for all other types at 100.000px

PR is on the way!

231

(9 replies, posted in Import DXF)

When the plugin is not found, you get the Message from attachment. (Language may be different)
If you click on "Installationsordner", the directory where to place the binary of plugin is opened in file-manager.
When the directory dos not exist, it will be created automatically and opened.

Back to the original question:

luf wrote:

Ich denke um eine solche Datei exportieren zu können, müsste ich im Quellcode in der Datei "exportdialog.cpp" auf den Zeilen 1011 und 1016 die range von 10'000px auf 100'000px erhöhen. Was denkt ihr?

Do you think there are technical reasons for the limits of 10.000px, Laurent?

As I wrote above, I created a local version on my Debian-box with the limits set to 100.000px and could export SVG with a width of

svg width="14882.6mm" height="11112.5mm"

see attachments in the post above: https://qelectrotech.org/forum/viewtopi … 993#p20993

Do you think it is possible to rise the limits in general?

Wenn ich mir das so anhöre mit "PDF kann nur 5 m", "10m x 2m - Drucker" und  so:
Ich hätte gerne das Endergebnis gesehen!
In welche Kunsthalle / Galerie kommt das rein? nomicons/wink

234

(7 replies, posted in Elements)

ok ... added!

For next rework:
Please use the elements from repository!
I added element-names and adjusted some terminal-positions!

... einen Anhang habe ich noch!

Hallo Luf,

bei QET und SVG sprechen wir in beiden Fällen von Vektor-Grafik! Also prima skalierbar! Deshalb wäre es schlecht, wenn Du Pixel-Bilder im Plan verwenden würdest!
Habe "gerade mal fix" einen QET-Export einer Folio auf 750x560px und nochmal auf 75000x56000px gemacht.
Wenn ich mir die beiden Dateien im Vergleich anschaue, sind dort "nur" andere Faktoren für "transform=matrix(..." angegeben.
O.k. - das sind ziemlich viele, aber die brauchst Du doch nicht händisch ändern: Dafür gibt es Inkscape!
Du exportierst also zunächst die QET-Datei so groß wie möglich und dann öffnest Du die SVG in Inkscape.
In den Dokument-Eignenschaften die Dokument-Größe auf die gewünschten Werte setzen und den Inhalt skalieren.
Ich kenne Deine Datei nicht, aber so wäre meine Vorgehensweise, solange Du die Sourcen von QET nicht selber kompilieren kannst.

EDIT: Hatte die Anhänge vergessen...

Gruß
  plc-user

Hallo Luf,

Das sind ja mal große Dinge, die Du vorhast!   nomicons/shocked

Willst Du Dir eine Wandtapete mit QET gestalten? nomicons/wink

Einige Vorgaben in QET sind so enthalten, weil sich die Entwickler nicht vorstellen konnten, daß jemand irgendwas anderes (oder wie in diesem Fall) größeres braucht! Ob genau diese Anforderung auch dazugehört oder ob es echte technische Gründe für die Werte gibt, kann ich nicht sagen.

Deine Formulierung suggeriert mir, daß Du die Werte für Deine lokale Installation schon eingetragen und kompiliert hast. Ist das so?
Und: Funktioniert das?

Diese Anforderung macht natürlich neugierig:
In welcher Branche werden (Schalt-) Pläne auf einer einzelnen Seite auf dann auch noch als SVG benötigt oder gefordert?

Gruß
  plc-user

238

(7 replies, posted in Elements)

Please read the names of attached files again, spotu:
Both files, that are attached have the same name and the same content!

239

(9 replies, posted in Import DXF)

@Pai54svt263:

Remark:
The version of QET_ElementScaler in the download-section of QElectroTech may not be the most recent and may contain errors, that are already fixed in official releases.

I recommend to always use the latest version of QET_ElementScaler available at github:
https://github.com/plc-user/QET_ElementScaler
In the release-section you find the latest binaries I made.
The source code could be even more up-to-date...

To check the version, call QET_ElementScaler from command-line without any parameter.
The version-number is shown within the first few lines.
At the moment Version 0.5.3 is available as compiled binaries.

Salut Laurent !

With the help of that shell script, all occurrences of more than x decimal places (default: 5) are searched for in all elements in the current directory.

This raises questions for me:
- Who knows this script?
- Who uses this script?
- Is it also available for win?

I have extended the call a little to only count the elements in official common collection.
With original setting of 5 or more decimals:

$ ./detect_elements_bad_coordinates.sh | awk -F ":" '{ print $1 }' | sort | uniq | wc -l
1190
$ 

search for 4 or more decimals:

$ ./detect_elements_bad_coordinates.sh | awk -F ":" '{ print $1 }' | sort | uniq | wc -l
2004
$ 

If I then know which files are affected: How do I fix them?
Should I really go through the file(s) by hand in a text editor and change the values? Or use the element editor to click on each graphical part to edit?
It would be much more practical if this were done automatically in the background by the software I use to create the graphics!

The decimal places are already limited to two in the element editor, don't we want to be consistent and write only two decimal places to the file?

241

(9 replies, posted in Import DXF)

You can only import dxf for Elements!
So the menu-entry is only available in Element-Editor!

242

(7 replies, posted in Elements)

spotu wrote:

Please replece elements Pilz X3 and PIlz IX1 (topic above) with corrected one in elements library.

Won't be possible, because you added the same file twice!

243

(8 replies, posted in Import DXF)

vadoola wrote:

So I did a quick look, I never quite finished the logic for nested blocks, so that is the problem here. I'll add it to the to do list. Thank you.

At least we don't need to discuss font sizes with this file: All texts are “painted” into the drawing by lines and polygons... nomicons/wink

244

(8 replies, posted in Import DXF)

The dxf contains Blocks in Blocks in Blocks in.....
That's currently not supported by dxf2elmt, but developer is working on it!
Use CAD-Software, to "explode" all blocks.
Then dxf2elmt produces beautiful elements!

245

(19 replies, posted in Terminal block generator)

andi11 wrote:

i made a deeper dive into the source of the plugin

Within the plugin i switched positions with the down button.
(...)
It looks as if the properties of the terminals are switched (ground and standart) and not, like i hoped the positions within the plugin.

LievenC wrote:

the solution is there only someone needs to implement it

The source code of qet_tb_generator has not been changed for four years. How high do you think the chances are that it is being worked on “today”?

The plugin is python code: Can't you perhaps get together with someone who "speaks" Python and see how the problem can be fixed, LievenC and andi11?
You seem to have already found the problematic part...

stefan.123 wrote:

I found out that if I can redeclare an element in the schematic, e.g. the "50_residual_current_circuit_breaker", to a "master" and then redeclare the "/10_electric/98_graphics/99_assembly_plan/01_thumbnails_mounting_plate/abb/012_abb_rcd_4p.elmt" from "thumbnail" to "slave" and then I can establish a link from schematic to mounting plate.
Is that really the only way to have mouning plate graphics linked to elements in the schematic?

Ja, im Moment ist das leider so! nomicons/sad

Und ich glaube, das steht auch nicht ganz oben auf der Prioritätenliste, wenn der Haupt-Entwickler wieder voll einsatzfähig ist.
Es besteht natürlich immer die Möglichkeit, jemanden zu finden, der C++ unter Qt programmieren kann und Spaß daran hat, an QElectroTech mitzuarbeiten! Vielleicht kennst Du jemanden, stefan.123? Oder vielleicht kannst Du selber teilnehmen?

Ich finde es immer sehr schade, wenn hier nach neuen supertollen Funktionen gefragt wird, aber scheinbar niemand bereit ist, sein/ihr Wissen und Können hier im Projekt einzubringen.

Ich bin hier auch ganz langsam angefangen und habe Fragen gestellt und inzwischen traue ich mich daran, bestehende Funktionen zu hinterfragen und bearbeiten! Und einige davon sind bereits in QET eingeflossen...

Das geht nicht gegen Dich, stefan.123!!!
Ich wollte das nur mal loswerden...

Gruß
  plc-user

scorpio810 wrote:

Thanks, plc-user. nomicons/wink

You're welcome!  nomicons/smile

Hello everyone!

What do you think about limiting the numerical values to two decimal places when saving elements with element-editor?
The background to the question.
For example, the elements contain such values (excerpt):

x1="-1.77636e-15" y5="6.91313" x5="-1.77636e-15"
dth="5.4" height="0.64596"/>
dth="5.4" height="0.64596"/>
idth="3" height="3.87576"/>
dth="3" height="3.87576"/>
idth="3.6" height="1.93788"/>

Where do these many decimal places come from?
Several possibilities:
- from a conversion tool
- copy and paste from the clipboard
- ???

I can't edit the third decimal place at the latest in the element editor itself because all input fields are limited to two decimal places.
Using mouse and keyboard, I can only move the individual graphical elements by a minimum of 0.1.
This means I can't change the values in such detail with on-board tools anyway!
How far do I have to zoom in the element editor to see the difference between “0” and “-1.77636e-15”?
So why all these decimal places?

I have included two screenshots in the appendix to show that the differences are hardly noticeable in most cases - not even with the selected (rather small) example element.

It's not like I'm just asking the question here and waiting for someone else to do the work: I've already prepared something and would like to ask your opinion on the topic, whether you think it makes sense too!

Looking forward to your comments!

Best regards
  plc-user

@iznobe:

Wir werden das gesamte Programm an elektrischen Geräten der genannten Hersteller gerne veröffentlichen, wenn Du die Elemente erstellt und uns zur Verfügung gestellt hast!

Online-Translation to English:
We will be happy to publish the entire programme of electrical devices from the manufacturers mentioned if you have created the elements and made them available to us!

Online-Translation to French:
Nous publierons volontiers l'ensemble de la gamme d'appareils électriques des fabricants mentionnés si tu as créé les éléments et nous les as mis à disposition!

scorpio810 wrote:
make -j48

I'm a little envious: I don't have 48 cores!  nomicons/wink