151

(9 replies, posted in Code)

Hello elevatormind,

Almost at the same time you posted your many qt6-changes, another user had another idea to solve the accidental movement of texts:
https://github.com/qelectrotech/qelectr … r/pull/363
I started a little discussion with pkess (in German, because we are almost neighbors) to figure out my reasons why I like your solution a little better: we wouldn't have to change the elements!
I tried your commit "selective_move" on my Debian stable development-VM today and must say: Works very good!
And we can possibly solve these reports: https://qelectrotech.org/forum/viewtopic.php?id=2899

Stalefiles are automatic Backup-files during runtime of QET.

Why do you want to delete the stalefile by hand? Maybe an "old" QET-Version?
see this post:
https://qelectrotech.org/forum/viewtopi … 869#p20869

In both cases the stalefiles are handled by QET:
When I press "Cancel" the files are deleted instantly and when I click "OK" the backup-files are used by QET and deleted, when closed.

Did you ever look in your Log-files?
"Menu" -> "Help" -> "About QElectroTech" -> Tab "Log"
There you'll find something like this:

14:06:08.447 Info:  For QET configuration-files: 
14:06:08.447 Info:  App Config Location: "/home/ich/.config/QElectroTech/QElectroTech" 
14:06:08.447 Info:  For data-files (user-/company-collections, titleblocks, etc.): 
14:06:08.447 Info:  App Data Location: "/home/ich/.local/share/QElectroTech/QElectroTech" 
14:06:08.447 Info:  Directory for project stalefiles:
14:06:08.447 Info:  Generic Data Location: "/home/ich/.local/share/stalefiles/QElectroTech/"

Depending on your system It may be another directory, but the entry in log-file starts also with "Generic Data Location:"!

We have already discussed this topic here in the forum:
It's about moved and then deleted elements with dynamic texts.
Sometimes there are remnants that remain outside the drawing area, but you can't see them and can't get rid of them for whatever reason.
Copying page content, pasting it onto a new folio and deleting the old page was the solution at the time.

Salut galexis !
Hello everybody!

galexis wrote:

It's not possible to integreted it directly on QET like it's C++?

Maybe you already noticed?

Available in current 0.100-dev-version of QElectroTech:
In the last few days I implemented mirror (shortcut <M>) and flip (shortcut <F>) into element-editor.
Also the rotate-function was reworked, so that rotating of ALL primitives is made in increments of 90° with <Space>.
Rotation with smaller increments of 5° can be made with "text", "dynamic_text", "line" and "polygon" with <Ctrl>+<Space>.

"Merci" to Laurent, who supported with building all binaries!

Best regards
  plc-user

156

(9 replies, posted in Code)

Hello elevatormind!

Welcome to QET forum from me too!

elevatormind wrote:

PS. I've done two other branches with small features that may or may not be useful, will push them up for evaluation and try to post something about them here in the forum

Such an announcement naturally arouses curiosity!
I can't wait to see what you have prepared for us....

Your first try to post here was successful: I guess you can do it again!  nomicons/wink

Best regards
  plc-user

Danke für das Lob!

Es hilft aber nicht wirklich, regelmäßig dieselbe Frage in verschiedenen Unterrubriken und in verschiedenen Sprachen zu stellen!
Wenn Du andere Beiträge im Forum gelesen hättest, würdest Du wissen, dass wir im Moment sehr knapp an Entwicklern sind.

Wenn es wirklich so einfach wäre, PDF-Links einzubauen, wie viele Leute hier im Forum behaupten, warum baut ihr es nicht selber ein und stellt den Quellcode hier oder bei github zur Verfügung?

Deine Anfrage war nur der Auslöser für diese Antwort, Pierre!
Es gibt noch soo viele andere, aus Benutzersicht "einfache" Dinge, die in QET einfließen können, aber wegen Personalmangel (noch) nicht werden...

Open-Source heißt nicht nur, dass Ihr es kostenlos nutzen dürft:
Ihr dürft am Quellcode mitarbeiten und dazu beitragen, dass QElectroTech noch besser wird!!!

158

(19 replies, posted in Terminal block generator)

andi11 wrote:

how can I attach files?

Click on button "Preview reply" then there is a button to search the attachment on your system.
Important: You have to click "Add file" to upload the attachment!

andi11 wrote:

I think i fixed it. I also did some more minor improvements in the files.
So posting it fix for the "sorting order" bug is not 100% correct, because it includes more changes.

I guess there are some users looking forward to it!

159

(7 replies, posted in Elements)

Salut Laurent !

It's not about fingerpointing here! nomicons/wink

scorpio810 wrote:

This is the best way of adding translations so far, without the svn/git differences being inflated by the hazardy registration of xml attributes since Qt 5X.

Another reason to try to sort arrtibutes in element-file.
That's why valoola and I should use the same order for attributes in output of dxf2elmt and QET_ElementScaler. Seems that we do...

160

(7 replies, posted in Elements)

Salut Laurent !

I do not like to contradict you, but the elements of the mentioned manufacturer and sub-dirs are identical in both collections!
Some elements seem to be edited using a text editor in order to add translations, while the element editor was used for the additional translation in a few cases.
And one subdirectory has been renamed.

Some of the elements in the official collection should be revised because, for example, the aspect ratios and scaling do not fit. Let's see if I can find some time for this...

luf wrote:

OMG, thats so great what you have implemented :0 Thank you a lot!

If we ever meet in real life: I'll have a cup of coffee!  nomicons/smile

luf wrote:

To the suggestion of plc-user, why i did not simply scale the svg file, it is because (at least in microsoft visio) the font-size doesn't change at all or at least not proportionally to the rest.

The company from Redmod has a "problem" with really open standards: As long as I know them, SVG is not supported (very well)!
That's why I suggested Open-Source-Software Inkscape

A colleague once started to ask: "With Inkscape, can I do ...?"
I interrupted him and said: "Yes!"
It turned out: It worked!  nomicons/smile

luf wrote:

But so if I understand you right, there will soon be an update that enables the export of those huge files?

Speaking of 0.10-dev: Export for large files is already available for some days now!

162

(7 replies, posted in Elements)

Why do you recommend contrib-elements, when we have so many parts from different manufacturers in official collection, Laurent? nomicons/wink
All Schneider-parts from contrib are also available in official collection!

Ich dachte bislang immer, dass Mammuts bereits ausgestorben sind ... war wohl falsch!  nomicons/wink

Versuche doch mal, diesen Thread durchzuarbeiten:
https://qelectrotech.org/forum/viewtopic.php?id=2861

Da ging es auch um Gruppierung von Seiten bzw. re-nummerierung von Seiten.
Vielleicht mußt Du Deine Verweis-Elemente und Schriftfelder anpassen!
Aber dafür gab es hier auch bereits reichlich Anfragen und Lösungen!

BTW:
Für Übersetzungen empfehle ich: DeepL

Thanks for the links, Laurent!

But we should open a new topc for that!

For now only this:
I have already tried to find a few places that seemed strange to me in terms of the result.

I noticed that the “bounding rect” is used for some functions. However, the “bounding rect” of individual parts is responsible for adding decimal places!

Try it yourself: Copy a rect with integer values for the position and paste it again: The rectangle appears at an integer position.
If a text on the left or right of the same rect is copied and pasted, the position is no longer an integer! And it also depends on font-size...
See the attached example.


EDIT:
Problem with paste-position is fixed in my latest PR at github!  nomicons/cool

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:

plc-user wrote:

It's not like I'm just asking the question here and waiting for someone else to do the work

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

In almost all cases, these many decimal places are caused by copy-and-paste in the element editor:
Depending on which parts and in which combination the parts are copied and pasted, the element editor inserts the content of the clipboard in strange positions.
The copy-and-paste function in the source code is complex and should be adapted by someone who understands more about Qt programming.
However, we can fix this by paying attention to it when saving.

A binary format of the element file would only disguise the problem...

Salut Laurent,

scorpio810 wrote:

I have mixed feelings when I see the post by Luf, who wants to make maybe 10 meters XXXXL plotter drawingof the medium-voltage system at the factory where he's doing his work placement.

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?

scorpio810 wrote:

I have a colleague who did the same on a 3 meters plan, for the 5.5KV cells and other TGBT on our industrial site since 63KV distribution.

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?

scorpio810 wrote:

I remember we limited the primitives in the element editor to two decimal places, (...)

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

Salut Laurent !

The fact that someone sits down and writes a script to recognize decimal places in order to minimize them in another script means to me that he is not satisfied with the many decimal places either.

And if I can avoid having to do additional work with one or even two external scripts, then I'll do it!
From my point of view, the element editor itself must ensure that the element file is “clean” and “tidy”.

In any case, I couldn't read any fundamental rejection from your lines, Laurent.
And all other feedback so far is also in favor of limiting the decimal places... nomicons/wink

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.

Salut Galexis !

Did you read my posts?
especially this one: https://qelectrotech.org/forum/viewtopi … 021#p21021

When the problem exists, it exists in all current flavors of QET!

But as I wrote:
I think I found what you mean and can fix it with the patch in this post:
https://qelectrotech.org/forum/viewtopi … 024#p21024

In the meantime I created a project with empty properties, saved the file and re-opened it again – et voila: see attachment!
Empty properties are saved and reloaded!

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!