Search options (Page 21 of 29)

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 ?

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

About the not updated language files:

Does anybody know how to solve this error?

Starte externes Werkzeug "/usr/lib/qt6/bin/lupdate /home/ich/Projekte/c_c++/QET/qelectrotech.pro"
WARNING: Could not find qmake spec 'default'.

"/usr/lib/qt6/bin/lupdate" mit Fehler beendet

Salut Laurent!

See the other Thread: https://qelectrotech.org/forum/viewtopic.php?id=2647 

Best regards
  plc-user

Why not create a subdirectory for drafts there?

Some time ago I already suggested implementing a second user collection (https://qelectrotech.org/forum/viewtopic.php?id=2105), but the limited number of developers for QET unfortunately prevents this.
That was meant for another reason, but could be useful here, too.

Hello rvamerongen,

you noticed, that you can have a User-Collection?

I created a User-Collection where I have a Sub-Folder for elements "in development" (see attachments).
Each with a separate "qet_directory"-file with a QET-name for the Sub-Folders...
This would be the place for your "templates".

Hello rvamerongen,

as far as I know photoshop can only handle pixel-graphic.
QET and Inkscape work with and produce Vector-Graphics.

If you have a pixel-graphic you have to work with "potrace" or the vectorising-features of inkscape to "trace" the graphic and thus create a vector graphic. In German Version of Inkscape: import a Bitmap to current file, click the image to mark it and then "Menü" -> "Pfad" -> "Bitmap nachzeichnen..." opens a tab where some parameters for tracing can be set.

When vectorised, converted to dxf, converted to QET-Element there is still much work to do, when you want to produce a fine-looking Element that only contains the necessary and visible parts. In the accu.elmt you attached earlier there are some polygons included that "blow up" the file-size but cannot be seen in the element because they are hidden behind the black rects! When I delete the invisible polygons, the file-size is reduced to less than half to 4.3kByte. When I adjust the English name of the element the file-size even reduces to 4.1kB...

But as I said in an earlier post:
For such simple Elements like the accu it would be much faster to draw it "from scratch" or you create yourself a template where for example a rect and some translations are included you'll be even faster in future!

EDIT: Of course I mean simple Elements can be drawn only with QET-Element-Editor!

I hope I haven't scared you off with these explanations!

Best regards,
  plc-user

Salut Laurent!

Thank you for your feedback!

I'll put the missing includes to the sources!

As already said:
I do not get any errors on Debian, ReactOS or Win10 ... strange.

Salut Laurent !

Je suis heureux d'apprendre que tu es de retour et que tu es sur la voie de la guérison !

Une première version est désormais disponible sur https://github.com/plc-user/QET_ElementScaler, qui tient compte des sauts de ligne pour les éléments "text". De mon point de vue, c'est déjà bien utilisable !

Mais ce qui n'est définitivement pas possible, c'est que le format SVG ne le supporte pas : Le formatage de texte à l'aide d'espaces !

Sans compter qu'il n'est pas de bon ton de formater un texte avec des espaces, plusieurs espaces sont supprimés par le visualiseur SVG (comme en HTML) !

Merci de tester la nouvelle version et de donner votre avis sur les résultats : Je ne peux pas vérifier seul tous les éléments QET (plus de 8000) individuellement ! Seule votre participation permettra d'améliorer le programme !

Cordialement,
  plc-user

"Das war Französisch" ... vom Online-Übersetzer

Hallo zusammen!

Auf https://github.com/plc-user/QET_ElementScaler gibt es nun eine erste Version, die bei "text"-Elementen die Zeilenunbrüche beachtet. Aus meiner Sicht ist das schon gut brauchbar!

Was aber definitiv nicht geht, weil das SVG-Format das nicht unterstützt: Formatieren von Text mit Hilfe von Leerzeichen!
Mal ganz davon abgesehen, dass es kein guter Stil ist, Text mit Leerzeichen zu formatieren, werden mehrere Leerzeichen (wie bei HTML auch) vom SVG-Betrachter unterdrückt!

Bitte testet die neue Version und gebt Rückmeldung zu den Ergebnissen: Ich kann nicht allein alle QET-Elemente (mehr als 8000) einzeln überprüfen! Nur durch eure Mitwirkung kann das Programm besser werden!

Gruß
  plc-user

und nun noch auf Englisch:

Hello everybody!

There is a first version on https://github.com/plc-user/QET_ElementScaler that recognises line breaks for "text" elements. From my point of view, this is already very useful!

But what definitely doesn't work because the SVG format doesn't support it: Formatting text using spaces!
Quite apart from the fact that it is not good style to format text with spaces, multiple spaces (as with HTML) are suppressed by the SVG viewer!

Please test the new version and give feedback on the results: I cannot check all QET elements (more than 8000) individually! The software can only improve with your cooperation!

Best regards
  plc-user

Hello Erik,

as Joshua also explained in this Post (https://qelectrotech.org/forum/viewtopi … 180#p19180) (see above):

In QET we have the CheckBox "closed" for a Polygon. Then the Start- and End-Points of are connected.
In SVG there is no such attribute: There is "Polyline" for "open" and "Polygon" for "closed".

The Element you mentioned has some "open" polygons so that's why a "Polyline" must be used for SVG.

Can you explain, why you think "Polyline" may be wrong or "not good"?

EDIT:
If you think the "kink" in the dashed line is not properly recognizable, then I must refer you to the creator of this element: The drawing is not correct!

These kinks in the dashed lines represent a kind of "notch" for the actuation, which (since I have been working in electrical engineering) is shown with a solid line. Only the notch, not the rest of the mechanical connection of the switching elements! In the attachment you find a screenshot from "Eaton Schaltungsbuch 2023" PDF-Page 485 (https://www.eaton.com/de/de-de/support/ … sbuch.html)

Have we found a volunteer here who wants to fix this error in the elements, Erik? 

Hello Erik,

Thanks for Testing, Erik! 
The line you are talking about is a dashed polyline and the "missing" part you mention is just a gap in this line.
If you open the SVG-file with a text-editor and change the stroke-dasharray="10,5" to perhaps "7,3" you'll find other parts of the same polyline "missing".

Maybe we need different dash-to-gap-ratio for different line-widths? 
Any suggestions?

I'm sure there's much more fine-tuning to be done...