Add the wire/cable catalogue manual (EN/FR/DE), pending PR #936
Documents the catalogue added by PR #936, in English, French and German,
each carrying the "Status: pending" notice until that PR merges.
Written as a cable manual rather than a wire one, because the data model
is a cable model: wirespec.h defines isCable() as numCores > 1, and the
per-core colours and sections, outer diameter, shield type and cable
family all exist because a cable has several differing cores. A
single-core wire is the degenerate case.
Every factual claim was checked against the source rather than the PR
description: the menu entry and dock behaviour (qetdiagrameditor.cpp),
the database path and its being global rather than per project
(wirecataloguedb.cpp), the fifteen IEC 60757 colours (iec60757.cpp), the
search matching section and core count as text, and what assigning a core
writes to a conductor, including the dashed shield and the green-yellow
bicolour pair (conductorpropertieswidget.cpp).
That check corrected one thing. The PR describes the terminal strip's
Cable column as a stub returning an empty string; what is actually there
is Cable and CableWire declared as column enums with no data source at
all. The page says the latter.
The page leads with what the feature is not, because conductors.md states
that QElectroTech has no cable object and that remains true: assigning a
catalogue entry copies values onto one conductor, and the Cable field it
fills is read by nothing. Linked both ways with each language's
conductors page, and added to the sidebar under Guides.
Getting a drawing out of QElectroTech was documented only as a chapter in
user_manual and, for the headless verbs, in cli_reference. The dialogs
themselves -- and the fact that there are three different paths with
different options and different remembered settings -- were not written
down.
From the source rather than the dialog labels:
- Print and Export to PDF are the same window; the PDF action just calls
ProjectPrintWindow::launchDialog with QPrinter::PdfFormat.
- Every default is quoted from ExportProperties::fromSettings: border and
title block on, grid, guides, terminals and terminal names off,
coloured conductors on, area "border". Fit in page defaults on, use
full page off.
- Print and image export keep separate settings, under print/default and
export/default, so configuring one does not configure the other.
- The print window offers no grid option at all, which is why the editor
grid never reaches paper.
Two PDF features that nobody could have known about were undocumented
and are now the part of the page most worth reading:
- cross-references and folio reports become clickable internal links,
automatically, on both the GUI and CLI paths (PdfLinks);
- element information can be attached as PDF pop-up annotations, a
PDF-only checkbox that is hidden when printing to paper, and which
skips reports and slaves.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CaKympWT3owLotCpEN2CFj
The most-used object in the program had no reference page. Conductors
are mentioned on 27 wiki pages and covered by none; every neighbouring
subsystem has a guide -- auto-numbering, folio links, terminal strips,
the nomenclature builder -- while the conductor itself had only a
chapter in user_manual.
Written from ConductorProperties and the export code rather than from
the dialog's labels, so each field says what reads it:
- the three levels settings come from (application, folio, conductor),
which are three different dialogs and do not rewrite each other;
- every field with its XML attribute, so a .qet file can be read;
- which fields fill which column of --export-cables, since that is the
only reason several of them exist;
- that --export-wiring cannot carry those columns at all: it reads the
project database, whose conductor table stores only the two terminals
and the wire number;
- Ctrl+K discards hand-routing, and a stored path that no longer matches
its terminals is silently dropped at load;
- F2 colours one conductor and refuses with several selected.
Two things stated plainly because users hit them and find nothing:
- Cable and Bus are stored, reloaded, shown in the dialog, and read by
nothing at all.
- There is no cable object -- no class, no database table, no grouping.
"--export-cables" is the from-to list, one row per conductor. A user
looking for cable management should know that before going looking.
Also records that named conductor presets do not exist (#461), which is
what a user was told to use on that issue and could not find, and links
PR #929 as pending rather than describing it as working.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CaKympWT3owLotCpEN2CFj
Holding Shift, Ctrl or Alt while dragging changes what the drag does, in
about twenty different ways, and almost none of it is discoverable. Two
appear in the status bar once a drag is already under way; the rest are
written down nowhere. keyboard_control covers the opposite problem --
working without a mouse -- so none of this was on the wiki.
Compiled by reading every Shift/Ctrl/Alt site in the source, 66 of them,
rather than from the ones I happened to know:
- Ctrl means "ignore the grid" everywhere, because the check lives inside
Diagram::snapToGrid() itself rather than at each call site, and it
rounds to the nearest pixel rather than freeing the position entirely.
- Shift on an element's own text moves the label instead of the element.
- Shift/Ctrl/Ctrl+Shift while drawing a rectangle or ellipse give square,
from-centre, and centred-square; centre-anchoring is decided at the
first click and deliberately not re-checked mid-drag.
- Alt on a shape's corner handle converts it to a polygon; Alt on a path
node or curve handle changes the node kind.
- Shift snaps rotation, skew and arc angles to 15 degrees.
- Alt+arrows nudge by the fine grid, Ctrl+arrows realign a text group.
- Ctrl+Shift is reserved by DiagramView for its own mode switch, so it is
not available as a modifier combination.
Two behaviours are called out as changing, with the open PR named rather
than described as working: element text not snapping (#927) and the text
tool having no cancel (#928).
Linked from _Sidebar.md and cross-linked with keyboard_control both ways.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CaKympWT3owLotCpEN2CFj
Add a Templates page, and correct how templates are placed
The wiki had no page on the Modèles tab, and the one sentence that
described it said a template is "dropped back in as a group at a click".
A click is exactly what does not work: clicking and double-clicking a
template are explicit no-ops in the code, and its context menu has no
insert entry. Drag-and-drop is the only route.
That sentence has a cost. An electrician reported the feature as broken
on the forum this month (viewtopic.php?pid=23296, item 5): "dans la liste
des modèles quand j'en sélectionne un que j'ai créé, il ne se dépose pas
sur le folio". He did what the wiki said and filed a bug.
The new page covers creating a template from a selection, placing one,
where the files live and how to relocate the folder, what a .qetmak
contains, how templates compare with elements and with copy/paste, the
limitations, and the four questions people actually arrive with.
Checked against the source and against a running build rather than
written from memory: the context-menu entry and save dialog were driven
by hand, the resulting .qetmak inspected, and the "double-click does
nothing" claim measured (two elements on the folio before, two after).
The placement gestures, the storage path and the file format come from
reading the code.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CaKympWT3owLotCpEN2CFj
Add a real answer for 'how do I find my elements faster'
Fixes a real inaccuracy while here: the page claimed drag-and-drop
'moves' elements, with common-collection drags being copies only
because you can't remove the source. Checked ElementCollectionHandler
directly -- there is no move() at all, only copy(), called
unconditionally regardless of source or destination. Every drag
copies. Also corrected what happens on a name collision: an
Erase/Rename prompt (RenameDialog), not a silent overwrite as I'd
first assumed before checking ECHSFileToFile::copy().
New §4: the concrete, verified workflow for building a personal
shortlist of frequently-used devices with the tools that already
exist -- a custom-collection folder, drag-to-copy, and the existing
'Show only this folder' solo filter -- since there is no dedicated
favourites feature to point to instead. States the one real
limitation (a copied element is a snapshot, not a live link to the
common-collection original) rather than leaving it to be discovered.
Cross-linked with keyboard_control.md, since 'select elements' is
ambiguous between finding one to place and selecting one already
placed -- this page is the former.
Add PLC modules how-to: I/O tables and linking a wire to a point
element_linking.md already documented the plcMasterData XML shape
(§5) but not the workflow: authoring the I/O table in the Element
Editor, setting a slave's state to 'Esclave PLC', and using
PlcLinkWidget (the 'Automate (PLC)' properties tab) to link a slave
to a specific row.
Includes one thing not obvious from either the UI or a skim of the
code: a PLC master's max_slaves is forced to -1 and
MasterElement::isFull() has no PLC-specific branch, so a PLC master
with every I/O row already linked still shows up in the linking tree
(rows struck through) rather than disappearing the way an ordinary
maxed-out master does. Verified directly in masterelement.cpp before
writing it down.
Linked both ways with element_linking.md and added to _Sidebar.md
under Guides.
Checked directly against ShortcutManager's registry, the menu
mnemonics, and the diagram/element editor keyPressEvent() handlers --
not assumed from the UI. States the one real gap plainly: placing a
new element from the Collections panel still requires a mouse drag,
verified by checking what double-click actually does there (opens
the Element Editor, not placement).
Linked from _Sidebar.md under Guides and cross-linked with
tips_and_tricks.md's existing shortcut list.
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>
Document Search & Replace and the nomenclature/summary query builder
Both were confirmed still-real gaps from the survey: Search & Replace
(sources/SearchAndReplace/, ~3,180 lines) was a single features.md bullet,
and the query-builder UI (sources/dataBase/ui/, ~1,088 lines) was only
named once inside project_database.md as a pointer to ElementQueryWidget,
with no workflow documentation.
## Search & Replace
The name is misleading and worth correcting up front: this is not text
find/replace. SearchAndReplaceWorker::applyChange() shows the real
semantics -- an empty field leaves a property untouched, a filled field
replaces it wholesale (never a substring swap), and a reserved sentinel
string (set via a per-field checkbox, never typed by the user) explicitly
clears a field. Three states per field, not two. Traced through
setupLineEdit()'s own doc comment and applyChange()'s three-branch
behavior to be sure of this before writing it down.
## Nomenclature / summary query builder
ElementQueryWidget (element_nomenclature_view) and SummaryQueryWidget
(project_summary_view) are a visual SELECT builder: two-list column
picker, seven filter modes with their exact SQL traced from
on_m_filter_le_textEdited()'s switch statement (No filter/Not empty/
Empty/Contains/Does not contain/Is equal/Is not equal), group-by and
count, an "Edit SQL query" escape hatch, and named saved configurations.
Explicit about what it is not: not a general SQL client (bound to one
view, can't change the FROM even in raw-SQL mode), and not the same
column set as --export-bom, which was verified to hardcode its own fixed
list in cli_export.cpp rather than sharing this widget's choices.
Links the existing one-line Search & Replace mentions in features (all
three languages) to the new page. EN/FR/DE for both.
Document managing collections: folders, writability, the two-tab panel
sources/ElementsCollection/ is the largest undocumented chunk found this
session -- separate from elements_XML (the file format) and
element_editor (drawing one element), nothing covered day-to-day
collection management.
The finding worth having written down: the common collection's read-only
status is not a filesystem permissions check. ElementsLocation::isWritable()
refuses anything under commonElementsDirN() unconditionally, by path --
that's why New folder/New element/rename/delete are greyed out there even
running as an administrator, and why dragging an element out of the
common collection copies it (there is no source to remove) while nothing
can be rearranged inside it. Custom and company are genuinely writable;
an embedded (project-internal) element follows the project's own
read-only state.
Also documents the panel's second tab -- Templates/macros, a reusable
diagram-fragment mechanism distinct from single elements, drag-dropped
onto a folio as a group -- and the full context-menu action set (new
folder/element, edit, delete with a real not-undoable warning, reveal in
file manager, reload from disk, the solo-folder filter, folder
properties).
Updates the Element Collections & Libraries stub in user_manual (EN/FR/DE)
to link here instead of the placeholder bullets from the correction pass.
EN/FR/DE.
Correct user_manual and add a preferences reference
user_manual.md read as confident-sounding but unverified filler, the same
failure mode already found and fixed in api_reference this session. Checked
every concrete claim in Projects & Folios, Working with Elements, Drawing
Wires, Reports, Preferences and the shortcuts table against the actual
source, and found roughly a dozen fabrications, not one or two:
- File -> New Project has no dialog at all (QETDiagramEditor::newProject()
creates the project and calls addNewDiagram() immediately) -- not a
three-step page-size/orientation/margin wizard.
- There is no "folio type" concept anywhere in the source -- no
single-line/multiline/control-diagram selector. Adding a folio
(addNewDiagram()) is likewise instant, no dialog.
- No per-folio "scale" property exists.
- "Auto-save, configure in Preferences" doesn't exist; there is a
20-minute crash-recovery backup timer with no exposed interval setting.
- The claimed element categories (01_Misc/03_Control/04_Energy/
10_Electrical) don't match anything in the collection -- real top-level
trees are 10_allpole/20_logic/30_hydraulic/50_pneumatic/60_energy.
- Every one of Rotate=R, Flip=H/V and Fit-to-page=Ctrl+0 in the shortcuts
table is wrong against ShortcutManager's actual registrations: rotate is
Space, fit-to-page is Ctrl+9, and flip doesn't exist at all for an
element placed on a folio -- flip (F) is element-editor-only, for
redrawing the symbol itself.
- No element-locking or persistent-grouping feature exists on current
master; removed rather than described.
- No wire-splitting mechanism exists (grep for split/conductor turns up
nothing); "wires only connect at terminals" already said correctly
elsewhere in the same file.
- No "Project -> Reports" menu or "I/O Documentation" report type exists;
nomenclature/wiring-list generation is File -> Export or the CLI
(--export-bom etc.), already documented in api_reference.
- The dynamic-text variable list (%id = "element ID", %label, %comment...)
contradicts this session's own verified variables.md -- %id is a folio
index, not an element reference number.
- No in-app "community element repository" browser exists.
- The claimed Preferences categories (Display/Projects/Grid) don't match
the five real pages (General, New project, Export, Print, Shortcuts).
Corrected or removed each, linking to the real mechanism where one of this
session's other pages already covers it (variables, api_reference,
project_database, element_editor, title_blocks, folio_links) rather than
re-describing it. Softened Multi-User Workflows with an actual caveat --
project_database.md already established there's no shared-state
mechanism, so "merge changes when working in parallel" needed the warning
that a merge conflict there is a raw XML conflict, not a structured one.
Applied identically across EN/FR/DE, not just the English source.
Adds a new preferences reference page (EN/FR/DE) covering what the real
five pages actually control, built from configdialog.cpp and
sources/ui/configpage/ directly: the six collection/title-block path
pickers on General (and why relocating one without a trailing slash used
to silently break IEC 81346 prefixes -- bugtracker #671), the New
project/New folio page's dual identity (same class, title and target
change depending on whether a project is open), and that Export and Print
share one underlying widget rather than being separate implementations.
Document using the element editor -- drawing tools, not just the resulting XML
sources/editor/ is ~22,900 lines and the only wiki coverage was a stub
telling readers to see the elements_XML reference for 'designing element
graphics' and 'defining connection terminals' -- which documents the
file format an element becomes, not how to use the editor that draws it.
element_linking already covers the master/slave/terminal semantics; this
covers the tool itself.
The finding worth having written down: width, height and hotspot have no
input dialog at all. ElementScene::toXml() derives them from the drawn
geometry on every save -- bounding rect rounded up to the next multiple
of 10 (with a quirk: a remainder over 6 rounds up an extra ten, which is
exactly the 42-to-50 example elements_definition_attribute.md already
used without explaining where the number came from), hotspot centered
in that box. And if the drawing doesn't straddle the scene origin,
centerElementToOrigin() actually moves every primitive on save, not just
the saved coordinates -- draw far from the crosshair and a save visibly
shifts everything.
Also: the checkElement() validation that runs before every save (0
terminals warns but doesn't block, except folio-report and
conductor-definition elements, which must have exactly one or the save
is refused); the Save vs Save As vs Save As File distinction (opened-from
location vs a collection picker vs a raw file picker); and the terminal
placement shortcuts (Space rotates through the four orientations while
placing, the tool re-arms at the same orientation for a row of pins).
Replaces the empty 'Creating Custom Elements' stub in user_manual (all
three languages) with links to this page, element_linking and
elements_XML instead of a four-bullet list pointing at one reference
page. EN/FR/DE.
Document DXF: two unrelated features reduced to one bullet each
sources/createdxf.*, sources/dxfpaintdevice.*, sources/dxf/dxftoelmt.*
total ~1,780 lines. The only wiki coverage was a single repeated bullet
-- 'DXF -- CAD format for collaboration' -- across features, faq and
user_manual, in all three languages, describing neither direction
accurately: it reads as one feature, and it's actually two that share
nothing but a file extension.
Export (File -> Export, alongside PDF/PNG/SVG, in-process) reuses every
item's existing paint() code through a custom QPaintEngine
(DxfPaintEngine) rather than a separate DXF renderer -- documented from
that class's own thorough header comment, including the real fidelity
table it specifies: rectangles and filled paths lose their fill (no
HATCH primitive in this DXF dialect), arcs become straight-line chords,
and images become position-preserving placeholder rectangles since DXF
has no raster entity here. No CLI verb exists for it, unlike PDF/PNG/SVG.
Import (element editor only, not the diagram editor -- File -> Import a
DXF file) is a symbol-authoring tool: it shells out to dxf2elmt, a
separate third-party program QET does not bundle, the same external-tool
pattern as qet_tb_generator already documented in api_reference. Traces
the actual call: , stdout read as .elmt XML, pushed
onto the element editor's undo stack as one operation.
Makes explicit what neither direction is: not a way to place a DXF
drawing on a folio, not round-trip safe (export's own limitations rule
that out before even considering the code is entirely separate), and not
a full CAD interchange path -- no layers, blocks or metadata, just
primitives.
Links the existing one-line mentions in features/faq/user_manual (all
three languages) to the new page instead of rewriting them, since they
are fine as list bullets. EN/FR/DE.
Document EDZ import: zero wiki coverage of a whole import format
sources/import/edz/ is ~1,150 lines (excluding the vendored LZMA SDK)
implementing import of EPLAN Data Portal parts, and the word 'EDZ'
appeared nowhere on the wiki -- not a passing mention, not a features
bullet, nothing.
The module already carries a thorough developer README; this restructures
it for the wiki rather than writing from scratch, verified line-by-line
against the source: the menu path, the exact field mapping (manufacturer,
order number, description and comment land in the same four
element-information fields the BOM already reads), the zip-vs-7z format
detection and its current 7z-only limitation, and the point most likely
to surprise a user -- the imported symbol is a generic generated
rectangle, not a copy of the EPLAN macro's geometry, because that
geometry is tokenised EPLAN PXF referencing EPLAN's own libraries with
nothing portable in it.
Also carries the module's EPLAN Data Portal Terms of Use notice forward,
framed as a description of what QET's reader does (parses only portable
factual data, reproduces no EPLAN-proprietary geometry) rather than legal
advice about the reader's own situation.
EN/FR/DE.
Collapse the wiki sidebar into click-to-expand sections
The sidebar had grown to 107 lines, 45 of them the two nested XML trees,
which pushed everything else off the screen.
Each section is now a <details> block. Getting Started, Guides and
Development are open by default; File formats and About are collapsed,
and the two XML trees are separately expandable inside File formats. Also
splits the old Reference section in two -- the how-it-works guides are
not the same kind of thing as the XML element tree -- and folds the
one-item Help Us section into About.
No links removed.
Document page/wire linking -- folio reports -- in the user's own words
Wires continuing across pages had no page anywhere: element_linking
covers master/slave cross-references, not next_report/previous_report.
Written with "page" and "wire" in the prose and a glossary mapping them
to folio and conductor, since that is how people ask about it.
The central fact, taken from LinkElementCommand::isLinkable(): QET checks
exactly two things when linking two reports -- matching inverse type, and
both being free. It does not check that they are on different pages, that
either has a wire attached, that the two wires share a potential, or that
the arrows point sensibly. A link is an assertion the user makes and QET
renders without verifying, so --export-links is the only real audit.
Also documents what was written down nowhere: a report's dynamic text is
restricted to five variables (folioReportInfoKeys), the label describes
the partner's position rather than its own, report terminals are
deliberately excluded from wire-number counts because they are not real
terminals, linking replaces rather than adds, and a report is only
clickable in an exported PDF when its text actually shows %{label}.
EN/FR/DE.
sources/titleblock/ is ~8,300 lines and the format was undocumented:
title blocks were mentioned in features and user_manual, but nothing said
how to author one.
Covers the grid model and the part that makes a template fit any paper
size -- the three kinds of column length, where an unprefixed value is
absolute pixels, t22% is a fraction of the total width and r100% takes
the remainder, while rows are always absolute. Also label-vs-value and
why only labels are normally translated, the more permissive variable
substitution used here (both %{name} and %name, longest key first, but
only the braced form is discoverable by the editor), the two logo storage
forms and the fact that bitmaps are forced to base64, the four collections
including the embedded one that makes a project self-contained, and the
cell tag names.
Notes F023 inline as a known defect: a logo whose storage attribute is
neither xml nor base64 is written back with no image data.
EN/FR/DE.
Document auto-numbering: three systems, sixteen part types, and freezing
sources/autoNum/ is ~5,085 lines, and the only wiki pages mentioning it
were 7-to-9-line XML reference stubs describing where it is stored.
Covers what a scheme actually is -- an ordered list of parts -- and all
sixteen part types: seven counters (with the per-folio variants and wrap's
modulus), seven context parts that take their value from the element's
position or folio, and string/alpha. Documents that format overrides the
type's natural zero-padding, and that alpha increments like a spreadsheet
column name.
The behaviours that surprise people and were written down nowhere:
- a scheme supplies sequences, a formula places them, and a %sequ_N whose
index the scheme does not define prints itself verbatim with no warning
- a new conductor joining an existing potential inherits its number; only
a genuinely new potential draws a fresh one, and a potential whose
conductors disagree opens the potential selector
- folio variables in a conductor formula resolve per conductor, not per
potential
- freezing exists at three scopes (project, folio, item), which is why a
project can hold labels that no longer match their formula
- a scheme with an empty title or formula is silently dropped on save
Also notes that terminal numbering is a separate feature honouring
auto_num_locked. EN/FR/DE.
Document terminal strips, 9k lines of shipped feature with no user docs
sources/TerminalStrip/ is 66 files and ~9,250 lines, and the words
"terminal strip" appeared on the wiki only in the roadmap, history,
vision and contributing pages -- discussed as a topic, never documented
as a feature.
Covers the part that actually causes confusion: the three-layer model of
strip / physical terminal / real terminal, where a physical terminal's
several real terminals are its levels, ordered back to front from the
mounting plate. Also the six conditions a selection must meet to be
bridgeable (the reason the button greys out), free terminals that exist
in the strip but on no folio, the four-level ceiling in the drawing that
the data model itself does not impose, and the <terminal_strips> XML.
States the honest caveats: the menu entry is labelled (DEV) in the
shipped source, and no example project contains strip data -- verified,
the 143 "terminal_strips" hits in industrial.qet are all element
collection paths, not strip data.
EN/FR/DE.
Document the variable and formula language, all five dialects of it
There is no single %-variable language in QET: element labels, conductor
texts, the folio field, title block cells and cross-reference labels each
resolve a different set, and a variable that works in one is left as
literal text in another with no error. The folio field is the sharpest
case -- it understands %autonum, %id and %total and nothing else, so the
%f and %{...} people reach for there print verbatim on every folio.
Also records two things the code says that nothing else documents:
- %f and %F are not interchangeable. %f is the folio index; %F inserts
the folio *field*, which defaults to "%id/%total" and so renders
"3/12". It works only because %F is expanded before %id and %total in
the same pass.
- AssignVariables::replaceVariable() is a hard-coded list, not a lookup
over elementInfoKeys(). Three omissions are deliberate (formula, xref,
exclude_from_bom) but machine_manufacturer_reference_auxiliary1..4 are
simply missing: the fields exist and can be filled in, the plain
machine_manufacturer_reference resolves, and the four auxiliary
variants stay on the drawing as literal text.
EN/FR/DE.
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.
Document the project database as what it is: a derived in-memory cache
The name invites the assumption that QET has a real database behind a
project. It does not -- projectDataBase is rebuilt from the .qet XML on
every open and never written back, and almost everything that makes the
current design safe follows from that: no schema version, no migrations,
a wrong row costs nothing, the database cannot disagree with the drawing.
Covers the lifecycle, the six tables and three views, why the schema is
generated from elementInfoKeys() at runtime, why the nomenclature filter
belongs in the view rather than the element table, and the terminal
identity problem -- Terminal::uuid() is a catalog position id shared by
every instance, which is why the primary key is (uuid, element_uuid) and
why stableUuid() derives one from geometry.
That last point is the one that matters for any future persistence work:
a guessed identity is a cache miss today and a one-shot migration of
everyone's projects if the database ever becomes the file format.
EN/FR/DE.
Document master/slave/terminal linking, the feature nothing in the collection uses
The element editor can declare a master's contact budget, cap how many
slaves may attach, mark a terminal as isolating a potential, and keep an
element out of the BOM. None of it was documented anywhere, and the
measured result is that none of it is used: of the 6918 elements in the
10_electric collection, 0 declare slaveContactGroups and 0 declare
max_slaves; no shipped example project uses auxiliary1-4.
Adds element_linking (EN/FR/DE) as a guide, and turns the one-line
kindInformations and elementInformations reference stubs into the actual
XML vocabulary, taken from ElementData::kindInfoToXml/kindInfoFromXml.
Records two traps worth knowing: max_slaves counts slave elements rather
than contacts, and potential_isolating / auto_num_locked /
exclude_from_bom are compared against the exact string "true".
Restates the 2023 refactoring plan (refonte_du_code_de_qelectrotech) as a
statement of direction, and says plainly what QElectroTech is not trying
to be.
Marked as a proposal at the top, not adopted policy, with review invited
from the active contributors. If it is adopted, development_roadmap needs
updating to match; if it is rejected, the page should be deleted.
The core position: QET will not become an EPLAN replacement and should
stop being measured against one. Its three defining properties -- a
project is one file, it opens anywhere, it is built by the people who use
it -- are worth more than feature parity, and a shared database or
mandatory central part data would trade them away.
Where it differs from the current roadmap is listed explicitly at the end
rather than left implied: seven items already delivered since 2023, the
SVG element format buying less than it is said to, the SQLite proposal not
distinguishing a derived cache from a source of truth, an inverted
dependency in the ElementInformation item, and the latest stable release
being January 2026 rather than January 2024.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
New Pages:
1. Home-FR.md (French Home page)
- Complete French translation of Home page
- Navigation links to French content
- References to Getting Started, Documentation, Development
- Quick reference table in French
2. quick_start_guide-FR.md (French Quick Start Guide)
- Complete French translation of Quick Start Guide
- Step-by-step instructions in French
- 10-minute tutorial for beginners
- Platform-specific instructions (Windows, macOS, Linux)
- Common tasks and troubleshooting in French
3. languages.md (Language Hub)
- Centralized language selection page
- Navigation for English, French, and German
- Translation status matrix showing progress
- Call for translators and contribution guidelines
- Language-specific resources and forums
- Quality standards for translations
Updates:
- Home.md: Added language selector link at top
- _Sidebar.md: Added Languages page link under Getting Started
Translation Status:
- English: ✅ Complete (all 15 pages)
- French: ✅ Started (Home, Quick Start)
- German: 📋 Planned (coming soon)
Note: This creates the foundation for multi-language support.
Future work: German translations, additional French pages.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GtMZqGEiUMvDBqcFvVG2vb
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
New Downloads page with:
- Quick links for all platforms (Windows, macOS, Linux)
- System requirements (minimum 512MB RAM, 100MB disk)
- Platform-specific installation instructions:
* Windows: Installer, portable, Microsoft Store
* macOS: DMG, Homebrew, AppImage
* Linux: Package managers (apt, dnf, pacman), Flatpak, Snap, AppImage
- First-run instructions: launch, create project, draw, save
- Troubleshooting section for common issues
- Keeping updated information
- Portable vs. installed comparison
- Uninstall instructions for all platforms
- Links to Quick Start, User Manual, FAQ, Forum
Updates:
- Sidebar: Added Downloads link prominently under Getting Started
- Home: Updated to link to Downloads page instead of external URL
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GtMZqGEiUMvDBqcFvVG2vb
Fills in every page the sidebar previously linked to but that was never
written, so the two XML formats are now documented down to their children.
Element side (children of <description>):
line, polygon, rect, ellipse/circle, arc, text, dynamic_text, terminal
Project side (children of <diagram>):
properties + property, defaultconductor, elements, conductors, inputs,
images, shapes, elementautonumfoliosequentials + its unit/ten/hundred
children, and collection's category
Everything is taken from the writer in the source rather than guessed --
PartLine/PartPolygon/PartRectangle/PartEllipse/PartArc/PartText/
PartDynamicTextField::toXml(), TerminalData::toXml(), Diagram::toXml() and
folioSequentialsToXml() -- and cross-checked against a corpus of 185 real
.qet files plus the .elmt collection. Examples are copied from real files.
Notable details that were not documented anywhere:
- a square ellipse is written as <circle diameter=...>, not <ellipse>
- the rectangle tag is <rect>, not <rectangle>
- polygon's closed="false" is written only when the shape is open, so an
absent attribute means closed
- <arc> angles are stored internally in 1/16 degree but written in degrees
- <text> alignment attributes are written only when non-default
- <properties> occurs both under <project> and under <diagram>, and
<inputs> both under <diagram> and inside each <element>
Also rewrites elements_child_description as an index of its children -- it
was a stub with duplicated entries, blank examples and empty attribute
lists -- and restores the sidebar nesting now that the targets exist.
Ref: qelectrotech/qelectrotech-source-mirror#816
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019p83QJDMeFVz2k9ePUpTyb
ispyisail