Search options (Page 11 of 31)

Salut Laurent !

to point 1:
One more reason to limit the decimal places: The smaller the element file, the faster it can be loaded!
This is not about loading x thousand elements: We are talking about saving one single element from the element editor!

Point 2:
No discussion: copy-and-paste is important and must and will be kept!

Points 3 and 4:
What I said before: I don't want to have to rely on a second tool to keep the element files tidy! Even if it were my own tool. Let the element editor do that itself!

to “BTW”:
That's a different issue! Let's tick off one topic first!

And as I already wrote in the opening post:

The code is ready to upload to github and create a PR!

Salut Laurent,

This seems to be a special application that has appeared for the first time in more than 15 years! Until a few days ago, such a size could not be exported at all with QET! Do you remember that we have just changed the maximum size of export files from 10,000 px to larger values?
No one has asked for larger values yet, have they?

Is that still your colleague? I hope so: Then please ask him what he used to create or edit the elements for his project. If I follow your reasoning: It probably couldn't have been the element editor, as it has a limit of two decimal places.

We can also ask Luf how and with which tool he creates and edits his elements.
Maybe he reads here, too?
@Luf: Do you need more than two decimal places in elements for detailed drawings of your schematics, Luf? Then what tool do you use to edit your elements?

I've “only” been working with QET and following this forum for six or seven years now, and I can't remember any request that someone couldn't draw their elements in sufficient detail because the decimal places in the element editor are limited to two. Do you know of such requests?

At the moment I still see no good reason not to limit the decimal places...!

Edited post!
-------------------------------------------------

Hallo Galexis!

Kannst Du kurz erklären, wofür du diese leeren Eigenschaftsfelder im Projekt benutzt?

(...)
-------------------------------------------------

Salut Galexis !

Peux-tu expliquer brièvement à quoi tu utilises ces champs de propriétés vides dans le projet ?

(...)

-------------------------------------------------

withdraw the question:
If not all the information from the template is entered when a folio is created, the fields should still remain so that something can be entered later.
I will put the diff above in a PR.

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?

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 !

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!

Back to the original question:

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?

ok ... added!

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

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

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

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?

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