Search options (Page 24 of 32)

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

Please create a new topic in the suitable forum-area for a new topic!

And do not post the same question in more than one sub-forum.