Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1 (Page 14 of 14)

https://github.com/RincolTech-Solutions … CONTEXT.md

https://github.com/GameKnightt/qelectro … t-audit.md

Ce que je vois vraiment sur les chantiers en Bouches-du-Rhône
Les apprentis que je forme arrivent presque tous avec Schémaplic vu à l’école. Après six mois en entreprise, la majorité bascule sur QElectroTech, plus polyvalent et mieux adapté aux projets réels. Les artisans marseillais que je croise sur les chantiers utilisent eDesign quand ils sont équipés Schneider, XL Pro³ quand ils sont équipés Legrand, et QElectroTech pour tout le reste.

Le déclic pour moi remonte à 2015. J’avais perdu trois heures à refaire un plan qu’un collègue avait égaré. Un apprenti m’a montré QElectroTech dans la semaine qui a suivi. Depuis, je n’ai pas ressorti le crayon. La modification en cinq minutes, le PDF envoyé au client dans la foulée, c’est une productivité qu’aucun outil papier n’atteint.

L’écart que j’observe le plus souvent n’est pas entre gratuit et payant, mais entre logiciel avec bibliothèque IEC 60617 et outil généraliste bricolé. Ce chantier de Vitrolles où le client était arrivé avec son PDF Canva reste un cas d’école : le contenu était juste, le rendu inutilisable.

Hello, thank you for checking that for me,

I’m tired and I’m going to get some rest, but this morning, the test with QElectroTech-0.200.1-qt6-EXPERIMENTAL-r9084-0608a585d_x86_64-win64.msi started in 0.3 seconds with 9000 elements, on my work little laptop, WOW just as it did on my powerful workstation running Debian unstable – brilliant. .

I haven’t noticed any bugs so far, nor any slowdown when loading my large projects and continuing my work.

Laptop intel Dell Inspiriron I5 13 gen 16Go RAM + 2 X 24" monitors on dock station: so 3 monitors used on Windows 11.

Great news on the MSI test — 0.3 s startup on the small laptop matches exactly what I measure over here, so Windows and Debian now tell the same story.

And now please get some proper rest — the legwork is covered. The patch set (autosave restore, the other Qt6 gap fixes, the perf bits) plus the full profiling and scaling write-up are ready on my side; I'll post the details and cut the PRs so everything is simply waiting for your review whenever you're back. Nothing here needs you tonight.

Since 6.11's toString() always emits ≥19 fields now (not just when features/axes are actually used) and 6.10's fromString() always rejects >17 fields — every font saved by a Qt 6.11+ build is unconditionally unreadable by any Qt ≤6.10.x build. Not a corner case triggered by unusual fonts — it will happen every time, for every font, the moment a project crosses that version boundary in either direction. Debian's current stable qt6-base package is 6.10.2 (what I tested against, and presumably what you have too) — which lines up exactly with your report, since the file was produced by a Windows build on newer Qt6.

So this is upstream, not something QET got wrong architecturally. QET's actual bug is narrower but still worth fixing regardless of what Qt does next: none of the fromString() call sites check the return value, so a version mismatch degrades silently into a broken font (empty family, invalid size) instead of a graceful fallback — and that's the part within QET's control regardless of which Qt versions end up compatible with each other upstream.