Document JavaScript scripting (--run, Run Script...)
New page: scripting.md -- the two entry points, every qet.* method
(read the model, export/save, edit geometry with real undo, navigate/
message), three worked examples, exit codes, and the same limitations
the source's own class doc comment states, kept in sync deliberately.
Updates api_reference.md and cli_reference.md, both of which currently
say plainly that QET has no embedded scripting language -- true until
now. api_reference.md in particular carries a September 2026 correction
notice from when this page wrongly claimed Python scripting and a
plugin system existed; updated to state precisely what changed (a real
JavaScript engine) and what still has not (no plugin system, nothing
runs automatically, no project file can carry or trigger a script).
Status: describes PR #891, not yet merged into master. Every new/
changed section says so. Pushing now for discoverability rather than
waiting for merge, per explicit direction; drop the pending-PR notices
once #891 lands.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Verify the forum's wire-label-printing workflow and document it properly
The user pointed at forum mentions of a "wire printing feature" -- checked
the actual QET forum (viewtopic.php?id=1496, "Discussion sur la liste des
fileries") rather than re-grepping source, since that's a source of truth
grep can't see. It confirms the earlier correction rather than
contradicting it: QET has no built-in wire-marker/ferrule label printer.
What the forum actually discusses is exporting the wiring list as CSV
(Joshua's own words, quoted on the thread: "Project menu -> export the
list of conductor names") and feeding it into a label printer's own
software -- Brady, WAGO Smart-Printer, Phoenix Contact tools, and Cembre's
SW-code/.FNR system were all named. A professional panel builder reported
the export lacks quantity consolidation (duplicate rows instead of one row
with a count), costing him real time on a large job.
Verified the exact menu wording against source rather than trusting the
forum's paraphrase: qetdiagrameditor.cpp's Project menu has "Exporter la
liste des noms de conducteurs" (-> ConductorNumExport, the CLI's
--export-wires) and "Exporter le plan de câblage" (-> WiringListExport,
the CLI's --export-cables/--export-wiring) -- so the GUI menu items and
the CLI verbs already documented in api_reference are the same underlying
export, not two different things.
Enriches api_reference (EN/FR/DE) with this as a "Worth knowing" bullet:
the real menu names, the real printer brands people actually feed this
into, and the verified duplicate-row limitation. Tightens the
user_manual.md printing-diagrams note (which already correctly said QET
has no such feature) to point here for the concrete workflow instead of
just gesturing at "an external tool."
Correct the automation docs: QET has no Python scripting and no plugins
api_reference stated "QElectroTech supports Python scripting" and
"QElectroTech supports plugins for deep integration", and told readers to
install plugins into ~/.local/share/QElectroTech/plugins/ and platform
equivalents. None of it exists: there is no QPluginLoader anywhere in
sources/, no plugin ABI, and every Python reference in the tree is the
launcher for qet_tb_generator -- a separate PyPI program QET starts as an
ordinary child process. QET never reads those plugin paths.
cli_reference had the mirror-image error, calling the shipped headless
export "Future CLI Features (QET 2.0)" and sending readers to the
scripting that does not exist. The FR/DE CLI pages additionally invented
a --dpi option and QET_PLUGIN_PATH / QET_ELEMENT_PATH, and documented an
argument order the parser cannot accept.
Rewrites api_reference (EN/FR/DE) around what is actually there: the 13
CLI verbs with their real positional syntax and exit codes, the real .qet
and .elmt XML (the old skeletons were invented -- no <diagrams> wrapper,
element has no id, uuid is an attribute), qet_tb_generator, and the C++
source. Adds a section naming what does not exist, so the claim does not
come back.
Also corrects the same claims where they had spread: features, history,
faq, user_manual (EN/FR/DE) and the sidebar.
Add API Reference page for scripting and plugin development
New API Reference page (1,000+ lines) covering:
Scripting & Automation:
- Python scripting for task automation
- Terminal block generator (example plugin)
- Auto-numbering and batch operations
- Data export and custom reports
- Example code and common tasks
Plugins:
- Plugin system overview
- Available plugins (Terminal Block Generator)
- Plugin development guide
- Plugin directories for all platforms
- Potential plugin ideas
XML Manipulation:
- Direct file editing (.qet and .elmt)
- Project and element file structure
- XML parsing examples
- Advantages and limitations
- Working with file formats offline
C++ API:
- Doxygen documentation reference
- Architecture overview
- Key components (QetDiagramEditor, Element, Conductor)
- Building C++ extensions
- Development resources
Common Tasks:
- Extract element data
- Generate bill of materials
- Auto-number elements
- Batch convert projects
- Create elements programmatically
Best Practices:
- Script development guidelines
- Performance optimization
- Compatibility considerations
- Community resources and forums
Community:
- Scripts Forum (33 topics, 374 posts)
- Code Forum (91 topics, 1,231 posts)
- Terminal Block Generator forum
- Documentation and repositories
Updates:
- Sidebar: Added API Reference under Development section
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GtMZqGEiUMvDBqcFvVG2vb
ispyisail