Search options (Page 22 of 31)

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

Ich weiß noch gar nicht, was ich davon halten soll:
Da wird in mehreren Forenbeiträgen der Wunsch nach einer zweiten Benutzer-Sammlung geäußert, aber niemand von den aktuellen Betreuern oder Entwicklern geht auf die Diskussionen ein. Die einzige Reaktion, die kommt: "Schöne Idee, aber ich habe keine Zeit..." und ein "Workaround".

Nach über zwei Jahren spreche ich das Thema nochmal an, und bekomme wieder nur den seinerzeit als "unpraktikabel" bewerteten Workaround zur Antwort.

Dann nehme ich mir die Zeit und implementiere die Funktion, und schon kommt jemand aus der Versenkung aufgetaucht, der seit mehr als zehn Jahren angeblich nichts mehr mit dem Projekt zu tun hat, sich auch nicht an der Diskussion hier beteiligt hat und lehnt das ab!

Merkwürdig!

Aber zurück zum Thema:

Die Tatsache, dass es nur zwei Sammlungen gibt, ist von mehreren Leuten hier im Forum schon als nicht ausreichend angesehen worden!

Meine Idee drei Sammlungen zu haben, ist Folgende:

• übergeordnete Sammlung mit allgemeingültigen Elektrotechnischen Symbolen oder der offiziellen QET-Sammlung

• Firmen- oder Benutzer-Sammlung mit speziellen Symbolen, die für die Benutzung in der Firma verwendet werden

• Spielwiese oder Sammlung "in Entwicklung" für den lokalen Benutzer

Ich hätte die eingefügte "Firmensammlung" auch unterhalb der Benutzersammlung anordnen und als "Spielwiese" oder "in Entwicklung" bezeichnen können. Die Bezeichnung ist aber ziemlich egal: Entscheidend ist die dritte Sammlung!

Im Büro hatte ich schon mit Kollegen die Diskussion: "In Deinem Schaltplan habe ich das Bauteil XY gesehen, das wir in unserer Sammlung noch nicht haben, wo ist das denn?" "Das liegt noch auf meiner lokalen Platte, weil das noch nicht in der offiziellen QET-Sammlung drin ist!" "Die Umschalterei mit den Sammlungen ist doch für die tägliche Arbeit unpraktisch! Da wäre es doch sehr sinnvoll, eine dritte Sammlung zu haben, wo die Firmen-Bauteile drin sind!" "Habe ich bei QET angesprochen, wurde als 'nicht schlechte Idee' bezeichnet, aber sie haben keine Zeit dafür!"

via online-translator:

I still don't know what to make of it:

There are several forum posts expressing the desire for a second user collection, but no one from the current maintainers or developers responds to the discussions. The only response I get is: "Nice idea, but I don't have time..." and a "workaround".

After more than two years, I raise the issue again, and once again only get the workaround that was deemed "impractical" at the time before.

Then I take the time to implement the function, and someone who has supposedly had nothing to do with the project for more than ten years and has not participated in the discussion here comes out of the woodwork and rejects it!

Strange!

But back to the topic:

The fact that there are only two collections has already been considered insufficient by several people here on the forum!

My idea of having three collections is as follows:

• a superordinate collection with general electrotechnical symbols or the official QET collection

• Company or user collection with special symbols that are used in the company

• Playground or collection "under development" for the local user

I could also have placed the inserted "company collection" below the user collection and labelled it "playground" or "under development". But the name doesn't really matter: the third collection is what counts!

I've already had discussions with colleagues in the office:
"I saw component XYZ in your circuit diagram that we don't have in our collection yet, where is it?"
"It's still on my local disc because it's not yet in the official QET collection!"
"Switching between collections is impractical for day-to-day work! It would make a lot of sense to have a third collection that contains the company components!"
"I asked QET about this, they said it was 'not a bad idea', but they don't have time for it!"

hmm ... strange:

ich@deb-devel:~$ dpkg -l | grep sqlite
ii  libqt5sql5-sqlite:amd64   5.15.8+dfsg-11   amd64   Qt 5 SQLite 3 database driver
ii  libqt6sql6-sqlite:amd64   6.4.2+dfsg-10    amd64   Qt 6 SQLite 3 database driver
ii  libsqlite3-0:amd64        3.40.1-2         amd64   SQLite 3 shared library
ii  libsqlite3-dev:amd64      3.40.1-2         amd64   SQLite 3 development files
ii  libsqlite3-tcl            3.40.1-2         amd64   SQLite 3 Tcl bindings
ii  sqlite3                   3.40.1-2         amd64   Command line interface for SQLite 3
ii  sqlite3-tools             3.40.1-2         amd64   Command line interface for SQLite 3 (tools)
ich@deb-devel:~$

Anyway:
I created a Pull-Request on github and added only the language-files for German, because you said you want to update the files.

Hope it works with your Toolchain!

[Edit]: The language-files created with "lupdate" and compiled with "lrelease" work here!

[Edit 2]: The bug that the path isn't set immediately is also corrected. -> From my point of view: The Company-Collection is fully functional!

Salut Laurent,
Hallo alle anderen!

In der *.pro-Datei war die Angabe "TRANSLATIONS" nicht auskommentiert, aber die Übersetzungen wurden dennoch nicht bearbeitet.

Im Debian-Repository ist nur die Qt-Linguist-Version aus Qt6 verfügbar, die die Angabe einer *.pro-Datei als "obsolet" ansieht!
Daher mußte ich den Befehl anpassen, damit die TS-Dateien erneuert werden:

/usr/lib/qt6/bin/lupdate -noobsolete sources/* -ts lang/qet_{ar,be,ca,cn,cs,da,de,el,en,es,fi,fr,hr,hu,it,ja,mn,nb,nl,no,pl,pt,pt_br,ro,ru,sk,sl,sr,sv,tr,uk,zh,zh-cn}.ts

und:

/usr/lib/qt6/bin/lrelease lang/qet_{ar,be,ca,cn,cs,da,de,el,en,es,fi,fr,hr,hu,it,ja,mn,nb,nl,no,pl,pt,pt_br,ro,ru,sk,sl,sr,sv,tr,uk,zh,zh-cn}.ts

So wurden nun alle angegebenen Sprach-Dateien aktualisiert.

Was meinst Du, Laurent?
Soll ich von meinen ersten Qt-Bemühungen einen Pull-Request im offiziellen Repository erstellen?

Gruß
  plc-user

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

Dans le fichier *.pro, la mention "TRANSLATIONS" n'était pas commentée, mais les traductions n'étaient tout de même pas traitées.

Dans le dépôt Debian, seule la version Qt-Linguist de Qt6 est disponible, qui considère l'indication d'un fichier *.pro comme "obsolète" !
J'ai donc dû adapter la commande pour que les fichiers TS soient renouvelés :

/usr/lib/qt6/bin/lupdate -noobsolete sources/* -ts lang/qet_{ar,be,ca,cn,cs,da,de,el,en,es,fi,fr,hr,hu,it,ja,mn,nb,nl,no,pl,pt,pt_br,ro,ru,sk,sl,sr,sv,tr,uk,zh,zh-cn}.ts

et:

/usr/lib/qt6/bin/lrelease lang/qet_{ar,be,ca,cn,cs,da,de,el,en,es,fi,fr,hr,hu,it,ja,mn,nb,nl,no,pl,pt,pt_br,ro,ru,sk,sl,sr,sv,tr,uk,zh,zh-cn}.ts

Ainsi, tous les fichiers de langue indiqués ont été mis à jour.

Qu'en penses-tu, Laurent ?
Dois-je créer une pull-request dans le dépôt officiel à partir de mes premiers efforts de Qt ?

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