Search options (Page 23 of 32)

As written in BugReport, the bug must be there since several releases:
The ReadyToUse-Version from November 15th and even the 0.9 AppImage from January this year show the same effects. I can't go further in history. I guess it was when the tags of "dynamic_text" were re-worked...

EDIT:
It's not when editing the texts: Opening the file is all you have to do to see the bug.

Salut Laurent !

Unfortunately, I had to create a bug report for the element editor:
The font sizes of the "dynamic_text" of older file formats are not handled correctly since some programme versions (see BugTracker). I have tested with the current DEV version and the 0.9 AppImage for Linux.

When the bug has been fixed, I will of course reapply my scripts to the original elements! But how do we proceed until then? I don't yet have enough experience with GitHub to be able to revert the current changes myself.

Sorry for the bad news!

Ok!

Then: Let's publish the changes!

Done!

Don't get me wrong: I want to keep these elements!
All I want is to get rid of those "input" inside the elements and replace them with "dynamic_text" to have elements that were created using the current version of element-editor!

In the attachment you find a *.tar.gz with updated elements.
Would someone who uses them regularly please test if they work as expected?

If so, I'll create a PullRequest with all 4089 updated Elements.

Texts are there but with font-size=0 

The tags for font-size in "input" and "dynamic_text" are different: Fixed that in source-code of QET_ElementScaler.

[Edit]:
Just as a question:
Do we have the option of using the element editor with command line parameters?
"Open" in the old file format and "Save to a file" in the current file format would be sufficient.

First version with translating html-entities is available as Source on github.
It's the first "brute-force"-version that's far from perfect. 
If someone knows if I can use the pugi-internal function "text_output_escaped" for this, please let me know!

In this context I corrected an error with text-size of "dynamic_text".

In another context I recommended the "Eaton Schaltungsbuch" formerly known as "Klöckner-Möller-Schaltungsbuch"

https://qelectrotech.org/forum/viewtopi … 215#p19215

There you find on PDF-page 504 that it should be EN IEC 81346-2 (see attachment)
On page 10-3 there are some examples from that standard.
But I don't know if QET follows this standard 1:1 ...

That's a fact: Drawings are not centered on PDF-page.
See also here:
https://qelectrotech.org/forum/viewtopi … 437#p18437

EDIT:
You can "play" with the settings for the rows and cols for your folio(s)
and (at least on Linux-Systems) you can enter margins for PDF-export.

@Laurent:

[Edited]
Can it be that there went something wrong with creating and "compiling" TS-files at your side?
In my understanding you wanted to create TS- and QM-Files? Please correct me, if I'm wrong!
The translated texts are available in the German TS-File in the PR.
The QM-File for English in git-repository is different from my locally "compiled" file.
Or should I create a PR with "my" files? You decide! 

Best regards
  plc-user

Salut Laurent!

Fixed with Pull-Request #275

Best regards
  plc-user

Was glaubt ihr, in wievielen wirklich großen Firmen mit einer eigenen IT-Abteilung, die sich um jede eingesetzte Software ausgiebig kümmert, QET eingesetzt wird?

Vermutlich nicht viele, da große Firmen besonderen Wert darauf legen, dass die eingesetzte Software aktiv betreut und weiterentwickelt wird, was wir von QET im Moment (und schon seit einiger Zeit) leider nicht behaupten können.

Wahrscheinlich sind es sogar überwiegend kleinere Firmen oder Planungsbüros, die jeweils nur eine begrenzte Anzahl an Ingenieuren haben, die sich um die Erstellung von Schaltplänen kümmern. Hinzu kommt, dass Software zum Erstellen von Schaltplänen oft relativ teuer ist, sodass besonders für kleinere Firmen das Preis-Leistungs-Verhältnis eine hohe Priorität hat. Daher wird Open-Source-Software wohl eher in kleineren bis mittelgroßen Firmen eingesetzt.

Eine Open-Source-Software in einer großen Firma einzusetzen ist bestimmt erstrebenswert und sollte auch bei der Entwicklung der Software beachtet werden, aber die Anforderungen und Wünsche der "Kleinen" darf dabei nicht vernachlässigt werden! (Das erlebe ich bereits bei Kauf-Software zur Genüge!)

Dort will niemand die mitgelieferte Bauteilsammlung separat aussortieren und auf einem Netzlaufwerk zur Verfügung stellen: Es ist meist schon genug Aufwand, die firmenspezifischen Bauteile zu betreuen!
Also wird die Software aus dem Installations-Paket installiert und verwendet. Das Einstellen der Verzeichnispfade ist dann schon ein "lästiges Übel".
Jeder Entwickler, den ich kenne, hat aber immer gerne eine "Spielwiese", auf der er sich mit seinen eigenen Bauteilen beschäftigen kann, bevor sie in die Firmensammlung übernommen werden. (In meinem Büro sind das drei von drei!)

So entstand die Idee und der Wunsch nach einer zweiten Benutzersammlung.

Das Argument "anpassbare Anzahl Benutzersammlungen" zieht meiner Meinung nach überhaupt nicht: Wenn das umgesetzt werden sollte, macht es keinen großen Aufwand, ob man nun 20 oder 30 zusammenhängende Zeilen vom Quellcode ersetzt!

Mit der heutigen Quellcode-Änderung ist auch der letzte bekannte Fehler ausgemerzt und könnte ohne weiteren großen Aufwand übernommen werden.

Wir sollten anderen Forums-Teilnehmern aber auch die Gelegenheit geben, sich zu diesem Thema zu äußern! Zumindest vor zwei Jahren war ich nicht der Einzige, der den Wunsch nach einer zweiten Benutzersammlung hatte...

via Online-Translator:

How many really large companies do you think use QET with their own IT department that looks after all the software they use?

Probably not many, as large companies attach particular importance to actively maintaining and further developing the software they use, which is unfortunately not the case with QET at the moment (and hasn't been for some time).

In fact, it is probably mainly smaller companies or planning offices that only have a limited number of engineers to create circuit diagrams. In addition, software for creating circuit diagrams is often relatively expensive, so that the price-performance ratio is a high priority, especially for smaller companies. Open source software is therefore more likely to be used in small to medium-sized companies.

Using open source software in a large company is certainly desirable and should also be taken into account when developing the software, but the requirements and wishes of the "little ones" must not be neglected! (I have already experienced this enough with purchased software!)

Nobody wants to sort out the supplied component collection separately and make it available on a network drive: It's usually enough effort to look after the company-specific components!
So the software from the installation package is installed and used. Setting the directory paths is then already an "annoying evil".
However, every developer I know always likes to have a "playground" where they can work on their own components before they are transferred to the company collection. (In my office, that's three out of three!)

This gave rise to the idea and the desire for a second user collection.

In my opinion, the argument "customizable number of user collections" doesn't hold water at all: if this were to be implemented, it wouldn't make much difference whether you replace 20 or 30 contiguous lines of source code!

With today's source code change, the last known error has also been eliminated and could be adopted without any further major effort.

But we should also give other forum participants the opportunity to comment on this topic! At least two years ago, I wasn't the only one who wanted a second user collection...