• scorpio810
  • scorpio810
  • QElectroTech Team Manager, Developer, Packager
  • Offline

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1

https://github.com/qelectrotech/qelectr … r/pull/483

ispyisail wrote:

Headless command-line export
Adds a headless (no-GUI) command-line export so projects can be rendered and
exported in batch / CI pipelines without opening the editor. This is a
long-standing request (qelectrotech.org bugtracker #171, GitHub #309; the
list export addresses @pkess's request in #162 to "export all connections as
a list").

Usage

qelectrotech --export-pdf    <project.qet> <output.pdf>
qelectrotech --export-png    <project.qet> <output_dir>
qelectrotech --export-svg    <project.qet> <output_dir>
qelectrotech --export-cables <project.qet> <output.csv>
qelectrotech --export-wires  <project.qet> <output.csv>

pdf — one multi-page document, one diagram per page.
png / svg — one file per diagram, named <NN>_<title>.<ext>.
cables — wiring list (one row per conductor) as CSV.
wires — list of distinct wire numbers as CSV.
How it works
The export request is detected in main() before SingleApplication
is created, so a batch run does not attach to / focus a running GUI
instance. A plain QApplication is used (offscreen-capable).
Rendering reuses Diagram::render() over
BorderTitleBlock::borderAndTitleBlockRect() — the same path the GUI export
uses — so output matches the on-screen drawing.
The image/PDF code lives in a new CLIExport namespace
(sources/cli_export.{h,cpp}); main.cpp only gains a small dispatch hook.
List exports
The CSV list exports reuse the existing exporters rather than duplicating
logic:

--export-cables → WiringListExport. To make it usable headlessly,
WiringListExport::toCsv() (which mixed CSV generation with a file dialog
and file write) is refactored: a new const method toCsvString() builds and
returns the CSV, and toCsv() now calls it before doing the dialog + write.
No behavioural change to the existing GUI export.
--export-wires → ConductorNumExport::wiresNum() (already a pure string
producer).
Testing
PDF/PNG/SVG verified against native example projects (e.g.
Habitat-Schemas_developpes.qet) — output opens and matches the GUI render.
--export-cables / --export-wires verified end-to-end: both exit 0 and
produce the same CSV the GUI exporters produce.

https://github.com/qelectrotech/qelectr … r/pull/485

ispyisail wrote:

CLI export: don't draw the editor grid in PDF/PNG/SVG output
#485


https://github.com/qelectrotech/qelectr … r/pull/488

kellermorph wrote:

Fix “Exclude from auto-numbering” and “Potential isolation” tick boxes fault #482
Closed
Potential Isolation option for terminals #471

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."Questions regarding QET belong in this forum and will NOT be answered via PM! – Les questions concernant QET doivent être posées sur ce forum et ne seront pas traitées par MP !
  • scorpio810
  • scorpio810
  • QElectroTech Team Manager, Developer, Packager
  • Offline

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1

https://github.com/qelectrotech/qelectr … r/pull/489

ispyisail wrote:

CLI: add verification & data-export tools (info, BOM, nets, links, check-elements, resave)
#489

Follow-up to #483, extending the headless CLI with six read-only tools. The structured outputs (JSON/CSV) are aimed at automation and AI-driven pipelines — the CLI is effectively QET's programmatic surface — plus an element-library validator.

| flag | output | purpose |
|------|--------|---------|
| `--info` | JSON | structural project summary: per-folio element/conductor counts, page size, free (unconnected) terminals, project totals |
| `--export-bom` | CSV | bill of materials, one row per element (from `element_nomenclature_view`, same source as the GUI BOM) |
| `--export-nets` | JSON | electrical nets (connected-terminal potentials) — connectivity ground truth, via `Conductor::relatedPotentialConductors()` |
| `--export-links` | CSV | element cross-references (master/slave/report), flagging unresolved links |
| `--check-elements` | stdout | validate one `.elmt` or a directory against the element schema (XML, root definition, bounding box, terminals); OK/WARN/FAIL, non-zero exit on failure |
| `--resave` | .qet | load and rewrite the project XML (round-trip integrity check) |

All read-only and **additive** — no change to the existing pdf/png/svg/cables/wires options. `run()` is adjusted to handle the differing argument arity (`--info` takes an optional output; `--check-elements` takes a path, not a project).

Built and verified on Qt5 + KF5 (Ubuntu). `--check-elements` validated against the full bundled element collection (0 false failures, agreeing with QET's own loader).

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."Questions regarding QET belong in this forum and will NOT be answered via PM! – Les questions concernant QET doivent être posées sur ce forum et ne seront pas traitées par MP !
  • scorpio810
  • scorpio810
  • QElectroTech Team Manager, Developer, Packager
  • Offline

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1

https://github.com/qelectrotech/qelectr … r/pull/490
CLI: clickable cross-reference hyperlinks in PDF export
#490

Brings the GUI's clickable PDF cross-reference / folio navigation (cd76b6a) to the headless `--export-pdf` path, via a shared helper — as discussed on #483.

Two commits, bisectable per your suggested order:

**1. Extract `pdf_links.{cpp,h}` shared helper.** Moves the link-injection logic and `convertUriToGoTo()` post-processor out of `ProjectPrintWindow` into a standalone translation unit. The scene→page mapping is passed in as a `PageGeometry` (transform + `devToPdf` + source-rect lookup) so each caller supplies its own correct geometry — the helper never assumes a `QPrinter`. `ProjectPrintWindow` stays a pure caller: it builds its `PageGeometry` from the printer page layout exactly as before. No behavioural change to GUI print; no class-structure changes.

**2. Wire into CLI `exportPdf()`.** Builds the geometry from the `QPdfWriter` (96 dpi, zero margins, page sized to the diagram → scale ~1, no centering) — rebuilt from scratch, not reused from the printer path — and calls the helper per page, then post-processes after the painter closes.

**Verified** on `examples/industrial.qet` (50 pages): the exported PDF contains 304 `/GoTo` + `/FitR` internal link annotations (0 leftover `/URI`), well-formed. Builds clean on Qt5 + KF5 (Ubuntu).

Independent of the CLI tools in #489.
*Developed with assistance from Claude (Anthropic).*

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."Questions regarding QET belong in this forum and will NOT be answered via PM! – Les questions concernant QET doivent être posées sur ce forum et ne seront pas traitées par MP !
  • scorpio810
  • scorpio810
  • QElectroTech Team Manager, Developer, Packager
  • Offline

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1

Good news regarding Windows code signing for QElectroTech!

We have made significant progress in setting up proper Authenticode signing for our Windows MSI packages through the SignPath OSS program.

Here is what has been accomplished:
- Our application to the SignPath OSS program has been accepted
- The GitHub Actions CI/CD pipeline has been fully configured to automatically submit signing requests after each successful Windows build
- The MSI artifact configuration has been set up to sign both the installer package and all nested executables and DLLs
- A first test signing request was successfully processed, with all verifications passing (source code origin, build workflow, malware scan)

We are now waiting for SignPath to activate the production certificate, after which every nightly Windows MSI build will be automatically signed with a trusted certificate.

This means that in the near future, users will no longer see the "Unknown publisher" warning when installing QElectroTech on Windows.

Thanks to everyone who encouraged us to pursue this — it has been a long time coming!

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."Questions regarding QET belong in this forum and will NOT be answered via PM! – Les questions concernant QET doivent être posées sur ce forum et ne seront pas traitées par MP !
  • scorpio810
  • scorpio810
  • QElectroTech Team Manager, Developer, Packager
  • Offline

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1

Fix issue on macOS: Not able to open a *.qet file with double click under osx:
https://github.com/qelectrotech/qelectr … issues/218

Thanks Ispyisail for the detailed trace.


New macOS build was uploaded.

Enjoy it! nomicons/wink

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."Questions regarding QET belong in this forum and will NOT be answered via PM! – Les questions concernant QET doivent être posées sur ce forum et ne seront pas traitées par MP !
  • scorpio810
  • scorpio810
  • QElectroTech Team Manager, Developer, Packager
  • Offline

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1

Hi to the whole community and all our friends!

We have a new PR (#513) that imports manufacturer parts from the EPLAN Data Portal (.edz files) into QET element collections — really useful for anyone working with industrial components day to day. What do you think? Are you interested in this feature?

Before we go further, though: any legal experts out there? The EPLAN Data Portal's Terms of Use (§5.4) restrict using .edz data to "EPLAN and products acquired from EPLAN," and as the lead manager of QET, I don't want to create problems with Eplan.

This matters to me beyond the legal risk too — QET often serves as a springboard for teachers, who go on to teach Eplan P8 afterwards. Students are then free to choose between the two programs depending on their future career path.

Eplan P8 and SEE Electrical are fantastic tools — I used them myself 26 years ago — but they're so complex that if you only touch them twice a year, it's hard to find your way around. I'd rather keep a good relationship with Eplan than win a feature war.

PR: https://github.com/qelectrotech/qelectr … r/pull/513

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."Questions regarding QET belong in this forum and will NOT be answered via PM! – Les questions concernant QET doivent être posées sur ce forum et ne seront pas traitées par MP !
  • scorpio810
  • scorpio810
  • QElectroTech Team Manager, Developer, Packager
  • Offline

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1

To complete the discussion: if we look at qelectrotech-elements and especially qelectrotech-element-contrib, there's already a huge amount of work done "by hand" for major manufacturers, across two very different kinds of content:

Electrical schematic symbols (20_manufacturers_articles):

ABB, Allen Bradley, Schneider Electric, Legrand, Phoenix Contact, Hager, Wago, Danfoss, Eaton/Moeller, Johnson Controls, Balluff, Aucom, April, Arduino, KNX, Hensel, Shelly, Sofrel, WEG, and more - dozens of manufacturer folders, some with very fine-grained sub-categories (PLC controllers, safety modules, frequency drives, sensors, power supplies...).

Mounting-plate thumbnails, drawn to exact physical scale (98_graphics/99_assembly_plan/01_thumbnails_mounting_plate):

A separate, even more painstaking body of work - ABB, Hager, Legrand, Bticino (myhome/Netatmo range), Jumo, Omron, Schaffner, Finder, GCE, Hiquel... Every part has to respect real-world dimensions (e.g. 1 module = 18 mm pitch), which is why a Team member's plc-user even wrote a dedicated "QET_ElementScaler" very great tool just to fix scaling on older parts.

One example to illustrate the scale of this manual effort: a single contributor (dtartas) submitted 925 elements across 293 directories for WEG, plus WAGO, SEW and LS Electric parts. Even then, sorting and merging that into the official collection still takes significant additional work that nobody currently has time for.

Not to mention the .DXF to .elmt converters – and I’d like to thank once again everyone who has worked on them, from the very first versions right up to the present day, and who transforms highly complex DXF files into QET elements.

So yes, the community model works - but it's slow, uneven across brands, and increasingly hard to maintain. We've even discussed moving whole manufacturer trees out of the official collection into element-contrib just to keep things manageable.


On the EPLAN import (.edz) itself, one nuance worth adding:

Paragraph 5.4 of the EPLAN Data Portal's Terms of Use protects their portal, not the manufacturer's symbols as such. The manufacturer remains the owner of their own data.

So instead of QET pulling .edz files directly from the EPLAN portal (which does create a problem with regard to Eplan), I think another path would be to offer this conversion tool to the manufacturers themselves.

Many large manufacturers have already invested in building both schematic symbols and scaled front-view/mounting graphics for Eplan, but have neither the desire nor the budget to put a team on redrawing all of that as .elmt. If the tool let them convert and validate an export they provide directly, I think this would:

  • avoid any conflict with the EPLAN portal's Terms of Use (the data no longer comes from the portal, but directly from the manufacturer)

  • put the manufacturer in charge of their own data (they validate what gets published)

  • give them a genuine commercial argument: free presence in a widely-used, free and open-source software, with no development effort on their side



This turns the question from "importing from EPLAN" into "a conversion tool offered to manufacturers" - which seems much sounder both legally and strategically for QET, and fits the dynamic we already seeing with current contributions.

Best regards,
Laurent

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."Questions regarding QET belong in this forum and will NOT be answered via PM! – Les questions concernant QET doivent être posées sur ce forum et ne seront pas traitées par MP !
  • scorpio810
  • scorpio810
  • QElectroTech Team Manager, Developer, Packager
  • Offline

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1

Hi everyone,

Just a quick note: I'm currently very busy  and not in great health at the moment, so my responses on the forum, emails, GitHub issues, and pull requests will be slower than usual for a while.

I'll get back to everything as soon as I can — thanks for your patience and understanding.

A big thank you to plc-user, Achim, kellermorph, Joshua, hairy_kiwi, Shane, etc. for reviewing and testing the PRs.

Best regards,
Laurent

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."Questions regarding QET belong in this forum and will NOT be answered via PM! – Les questions concernant QET doivent être posées sur ce forum et ne seront pas traitées par MP !

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1

You no longer create readytouse versions ?

  • scorpio810
  • scorpio810
  • QElectroTech Team Manager, Developer, Packager
  • Offline

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1

Salut Alexis,

elle est nommée portable version.
Sur cette page la 4 eme option liste les builds -> https://qelectrotech.github.io/qelectro … ce-mirror/
https://github.com/qelectrotech/qelectr … ag/nightly
qelectrotech-0.100.1+git8939-x86-win64-readytouse.zip

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."Questions regarding QET belong in this forum and will NOT be answered via PM! – Les questions concernant QET doivent être posées sur ce forum et ne seront pas traitées par MP !

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1

C'est plus ici : https://download.qelectrotech.org/qet/builds/nightly/ ?

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1

Dans les nouvelles versions readytouse, il n'y a plus le dossier conf avec les éléments et cartouches perso ?

  • scorpio810
  • scorpio810
  • QElectroTech Team Manager, Developer, Packager
  • Offline

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1

Le conf des ancienes versions readytouse ne contenait que des dossiers vides.
[16:17:08] laurent@debian:~/paquet_qet/readytouse_base/conf$ tree
.
├── elements
├── elements-company
├── titleblocks
└── titleblocks-company

5 directories, 0 files

Puisque l'user est censé ecraser le conf vide et y remettre son ancien dossier conf....qui contient ses symboles, et cartouches personnel..

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."Questions regarding QET belong in this forum and will NOT be answered via PM! – Les questions concernant QET doivent être posées sur ce forum et ne seront pas traitées par MP !
  • scorpio810
  • scorpio810
  • QElectroTech Team Manager, Developer, Packager
  • Offline

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1

galexis wrote:

C'est plus ici : https://download.qelectrotech.org/qet/builds/nightly/ ?

Non, un CI/CD a été écrit et rajouté, c'est plus propre, plus de cross-compilation MXE.cc depuis ma Debian, le CI/CD tourne dans un environnement Windows Server 2025 with Visual Studio 2026 il produit l'installeur, la ready-to-use et aussi le MSI pour un déploiement en entreprise, c'étais l'une des demandes de la fondation signpath.io pour nous fournir un certificat voir https://github.com/qelectrotech/qelectr … issues/445

https://github.com/qelectrotech/qelectr … -build.yml
https://github.com/qelectrotech/qelectr … ws-msi.yml
https://github.com/qelectrotech/qelectr … te-page.py
https://github.com/qelectrotech/qelectr … roTech.wxs

https://github.com/qelectrotech/qelectr … ux/windows

C'est reproductible, traçable, et le MSI même s'il n'a pas encore le certificat est comme le bundle macOS aarch64 est lui aussi envoyé et examiné chez signpath.io afin qu'il soit contrôlé et ne contienne aucun virus, ci ce n'est pas le cas il est refusé!
c'est ce qui devrai t'intéresser le plus a ton travail. A voir avec ton service IT.

Je rappelle que le binaire le .exe et les bibliothèques DLL sont communs aux trois paquets.

L'installation du MSI est un peu plus longue, mais c'est celle que je privilégierai pour le boulot. Enterprise / GPO deployment.

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."Questions regarding QET belong in this forum and will NOT be answered via PM! – Les questions concernant QET doivent être posées sur ce forum et ne seront pas traitées par MP !

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1

scorpio810 wrote:

So instead of QET pulling .edz files directly from the EPLAN portal (which does create a problem with regard to Eplan), I think another path would be to offer this conversion tool to the manufacturers themselves.

After all, Eplan files are also available directly on the manufacturers' websites. That means you could import the files without using the Eplan Portal. For example, I don't have access to it myself, but I could download the files directly from the manufacturer's website. So it would still be great to integrate that tool directly into QET.

  • scorpio810
  • scorpio810
  • QElectroTech Team Manager, Developer, Packager
  • Offline

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1

Kellermorph wrote:

After all, Eplan files are also available directly on the manufacturers' websites. That means you could import the files without using the Eplan Portal. For example, I don't have access to it myself, but I could download the files directly from the manufacturer's website. So it would still be great to integrate that tool directly into QET.

Yes, if it's an external CLI program or maybe a Python script — like dxf2elmt, QET_ElementScaler, qet_tb_generator-plugin, etc.

The issue isn't where the .edz file comes from (portal vs. manufacturer website) — it's that merging this into the official QET repository would put QET itself, and me as the project's maintainer, directly in EPLAN's line of sight. If their legal team ever decided to challenge this, it wouldn't be you who got sued — it would be the project and me.

We've seen this pattern before with proprietary formats and FOSS software — DWG and Autodesk being the classic example: https://en.wikipedia.org/wiki/.dwg

Since you're German, you may find it easier to reach out to EPLAN directly than I would. Until we have something written and signed from their legal department, I won't merge this PR into the official repository.

In the meantime, anyone who needs this feature can apply the patch from the PR, compile QET themselves, and use it that way.

Best regards,
Laurent

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."Questions regarding QET belong in this forum and will NOT be answered via PM! – Les questions concernant QET doivent être posées sur ce forum et ne seront pas traitées par MP !
  • scorpio810
  • scorpio810
  • QElectroTech Team Manager, Developer, Packager
  • Offline

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1

Interesting : https://eplan.help/administration/en-US … amples.pdf
They are not against FOSS. nomicons/wink

EPLAN uses the dotNetRDF © library: http://www.dotnetrdf.org, Copyright (c) 2009-2013 dotNetRDF
Project (dotnetrdf-develop@lists.sf.net). The source code is subject to the MIT license: https://opensource.org/licenses/MIT

EPLAN uses Google Chromium ©, Version 88. https://www.chromium.org, Copyright © 2015 The
Chromium Authors. The source code is subject to the BSD license.

EPLAN uses the Chromium Embedded Framework ©, Version 4324. https://bitbucket.org/chromiumembedded/cef, Copyright © 2008-2020 Marshall A. Greenblatt. Portions Copyright © 2006-2009
Google Inc. The source code is subject to the BSD license.

EPLAN uses CEFSharp ©, Version 88. https://cefsharp.github.io, Copyright © The CefSharp Authors.
The source code is subject to the BSD license.

EPLAN uses Microsoft Unity ©, Version 4.0.1. https://github.com/unitycontainer/unity, Copyright © Microsoft. The source code is subject to the Apache license, Version 2.0.
This application incorporates Open Design Alliance software pursuant to a license agreement with
Open Design Alliance. Open Design Alliance Copyright © 2002–2020 by Open Design Alliance. All
rights reserved.

EPLAN uses CEFSharp ©, Version 88. https://cefsharp.github.io, Copyright © The CefSharp Authors.
The source code is subject to the BSD license.

EPLAN uses the Open Source software 7-Zip (7z.dll), Version 16.00, Copyright © by Igor Pavlov. The
source code of 7-Zip is subject to the GNU Lesser General Public License (LGPL). The source code of
7-Zip and details on this license can be found on the following Web site: http://www.7-zip.org

EPLAN uses the Open Source software Open CASCADE, Version 7.5.0, Copyright © by Open
CASCADE S.A.S. The source code of Open CASCADE is subject to the Open CASCADE Technology
Public License. The source code of Open CASCADE and details on this license can be found on the
following website: http://www.opencascade.org

EPLAN uses the the Open Source software QR Code generator library, Version 1.2.1.
https://www.nayuki.io/page/qr-code-generator-library, Copyright © by Project Nayuki. The source code
is subject to the MIT License.

The complete license texts for the Open Source licenses mentioned above are available in the following file:
<Installation directory>\bin\License.txt

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."Questions regarding QET belong in this forum and will NOT be answered via PM! – Les questions concernant QET doivent être posées sur ce forum et ne seront pas traitées par MP !