Vision
⚠ This page is a proposal, not adopted policy
It is offered for discussion and has not been agreed by the project maintainers. Nothing here binds anyone, and it should not be cited as settled direction until it has been reviewed.
Written 2026-09-11 by @ispyisail. Review welcome from @scorpio810, @plc-user, @Kellermorph, @arummler, @IBSYSLevi and anyone else with a stake — including disagreement, which is the point of publishing it.
It restates and updates the 2023 refactoring plan (
refonte_du_code_de_qelectrotech), and where it differs from Development Roadmap it is because the premise did not survive checking against current code. Those differences are listed at the end. If this page is adopted, that page needs updating to match; if it is rejected, this page should be deleted.
What QElectroTech is for, what it will not try to be, and the direction the code is heading.
This page is about why and what for. The concrete task list lives in Development Roadmap; where the two disagree, this page states the intent and the roadmap states the work.
What QElectroTech is
A free, open-source electrical CAD program for drawing schematics and getting a panel built from them.
Three things define it, and they are worth stating plainly because every decision below follows from them:
- A project is one file. You can email it, copy it to a USB stick, put it in git. There is nothing else to install, configure or connect to.
- It opens anywhere. A
.qetcarries its own symbols, so it opens on a machine that has none of your element library installed. Hand it to a colleague, a contractor, or yourself in five years. - It is built by the people who use it. Electricians, panel builders and engineers contributing symbols and fixes, not a vendor selling licences.
What QElectroTech will not try to be
It will not become an EPLAN replacement, and it should stop being measured against one.
That is not modesty, it is arithmetic. EPLAN is built by paid full-time teams around a shared SQL database, central master part data, and decades of vertical depth in one industry. QElectroTech is roughly 167,000 lines maintained by a handful of volunteers, with one person carrying the maintainer's workload.
Chasing feature parity would fail, and it would cost the three properties above on the way. A shared database means a server to administer. Central master data means a project that will not open without it. Both trade away "one file, opens anywhere" — the very thing that makes QET useful to a one-person panel shop.
So the goal is not to be a cheaper EPLAN. It is to be the best tool in its own category: the electrical CAD you can open on any machine, hand to anyone, and build from.
What we optimise for
These are the tie-breakers when a design decision is genuinely balanced.
- Portability beats capability. If a feature would make a project require something outside its own file, the feature needs a very good reason.
- The file stays readable. A
.qetis XML: diffable, mergeable, recoverable by hand when something goes wrong. That is worth protecting. - Reports you can build from. A drawing that cannot produce a usable bill of materials, wiring list and terminal plan is only half the job.
- Small changes that can actually be reviewed. The project's bottleneck is review capacity, not ideas. A large correct change that nobody can review is worth less than a small one that merges.
- Nothing that only works for experts. The person using QET is often an electrician with a panel to build, not a CAD specialist.
Where the code is going
Data: faster projects, without giving up the file
Opening a project today re-parses the whole XML and rebuilds every internal table; saving re-serialises the entire project even for a one-field change; images are base64 inside the XML and are decoded and re-encoded every cycle. On small projects this is invisible. On large ones it may not be.
The direction is a zipped project folder — the XML, a database, and plain folders for images, elements and title blocks — reached in steps that are each useful on their own:
- Measure. Establish whether the cost is real on large projects before spending anything on it. If it is not, stop here.
- Complete the internal database so it can answer every question the XML can — images, shapes, texts, tables, terminal strips.
- Persist it beside the project, stamped, rebuilt whenever it is stale. Fast opens, and deleting it loses nothing.
- Adopt the zip container, with the XML still the source of truth. Images become real files instead of base64.
A fifth step — making the database the source of truth instead of the XML — is deliberately not part of this plan. It would buy incremental saves, and it would cost permanent migration of every existing project, a file you can no longer diff, and a schema change becoming a migration forever. That is a decision to be taken on evidence, not momentum, and it has not been taken.
The distinction that matters: the internal database today is a derived cache, rebuilt from the XML on every open. A wrong row costs nothing, a new column needs no migration, and it cannot disagree with the drawing. Persisting that cache keeps every one of those properties. Replacing the file with it keeps none.
Code: decoupling, continuously
The 2006 codebase carries the usual debt of a long-lived project: large classes, serialisation mixed into domain objects, editor logic bound to the widgets that display it. This is being unpicked gradually rather than in one rewrite — per-shape classes, externalised handle management, and conductor creation moved out of the editor have all already landed.
The remaining work is ordinary refactoring, best done in small pieces attached to real changes rather than as a project of its own.
What we are explicitly not doing
Saying no clearly is part of a vision.
- Multi-user concurrent editing. It needs a server. It breaks "one file".
- Becoming a general 2D CAD. QET draws schematics and panel layouts. For true-to-scale mechanical drawing, other tools already do it better.
- A mandatory central parts database. A catalogue that fills in part data is welcome; one a project cannot be opened without is not.
- Replacing the project file with an opaque format unless the evidence makes the case and a maintainer commits to owning the migration.
Honest status
- Latest stable release: 0.100, January 2026. Development continues toward 0.200.
- Qt6 is now the default build; the Qt5 track has been retired.
- Around five people contribute code in a given year, and one carries the review load. That number, more than any technical constraint, sets how fast the direction above can be realised.
If a proposal cannot be reviewed by one tired person in a sitting, it needs splitting before it needs building.
Where this differs from the current Development Roadmap
Listed explicitly so the disagreement is reviewable rather than implied.
1. Seven items are already delivered. The roadmap lists these as planned; they exist in master today:
| Listed as planned | Actually in the code |
|---|---|
| Element prefixes from a standards file | qet_labels.xml, IEC 81346-2 letter table |
| Shape handles managed externally | QetGraphicsItemModeler/qetgraphicshandleritem.* |
| A class per shape primitive | nine part*.h classes in editor/graphicspart/ |
| Multiple references per element | auxiliary1–auxiliary4 in elementInfoKeys() |
| Externalise conductor creation | sources/utils/conductorcreator.cpp |
| Electrical potential for conductors | relatedPotentialConductors(), used by numbering and nets |
| SVG capability | --export-svg |
2. .elmt as SVG does not buy what it is said to buy. The stated benefit
is enabling SVG import. Import is a converter problem — dxf2elmt already
demonstrates the pattern, and QET already exports SVG. SVG also has no
concept of terminals, link types or dynamic text, so the format would need
metadata in a foreign namespace regardless: "SVG plus a QET namespace", which
is what .elmt already is minus the SVG part. Against that sits a permanent
migration of 6,918 collection elements and every user's custom ones. The
benefit looks reachable without the cost.
3. "A .sqlite containing all project information" needs resolving. As
written it sits alongside "a greatly simplified .qet file", which leaves it
unclear which of the two holds what. More importantly it does not distinguish
a database that is a derived cache from one that is the source of truth —
the single most consequential choice in the whole plan, and the one this page
proposes taking deliberately rather than by drift.
4. ElementInformation interfacing with the database inverts a
dependency. The database is populated from element information; having
element information read back from it is the wrong way round while the
database remains derived.
5. A factual correction. The roadmap gives the latest stable release as
"v0.100 (January 25, 2024)". The 0.100 tag's commit date and its GitHub
release are both 25 January 2026.
Provenance
This page restates and updates the 2023 refactoring plan
(refonte_du_code_de_qelectrotech, Joshua / black_sun_2012, February 2023),
which remains the origin of most of the technical direction here.
Three years on, parts of it have been delivered — standards-based element prefixes, per-shape classes, externalised shape handles, externalised conductor creation, multiple references per element — and parts have been revised where the premise did not survive contact with the code. Those revisions are noted in the roadmap rather than here.
Getting Started
🌐 Languages — English · Français · Deutsch
Guides
Conductors — wire properties, what feeds which export, and cables
Wire & cable catalogue — cable types, IEC 60757 core colours, assigning a core to a conductor
Printing and exporting — paper, PDF, images, and what each path does differently
Linking elements — master, slave, terminal
PLC modules — I/O tables and linking a wire to a specific point
Using the element editor — drawing tools, saving, checks
Preferences reference — what each settings page does
Keyboard-only control — mouseless QET, and the one real gap
Mouse modifiers — what Shift, Ctrl and Alt change while you drag
Managing collections — folders, writability, building your own shortlist
Templates — reusable multi-element blocks, and why clicking one does nothing
Search & Replace — bulk property changes
Building a nomenclature query — the BOM/summary table builder
Linking wires across pages — folio reports
Variables & formulas — %f, %{label}, sequences
Auto-numbering — schemes, sequences, freezing
Terminal strips — strips, levels, bridges
Title block templates — the .titleblock format
Importing EPLAN parts (.edz) — EPLAN Data Portal
DXF import & export — two unrelated features, one format
The project database — the in-memory SQLite cache
Development
Automating QET — CLI, XML formats, external tools
CLI Reference — command line usage
JavaScript Scripting — --run, geometry editing, undo
Vision — proposal, under discussion
