Search options (Page 11 of 31)

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

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:"!

Salut galexis !
Hello everybody!

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

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

Salut Laurent !

It's not about fingerpointing here!

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

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

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! 

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

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

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

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?