Feature idea: structured conductor data (DB table + folio cross-reference links) to support FreeCAD/3D wire-length tools

[ispyisail]

Forum thread: https://qelectrotech.org/forum/viewtopic.php?pid=21352#p21352
Related third-party project mentioned in the thread: QetWireManager — a community-built FreeCAD script that imports conductors from a .qet project to compute wire lengths in 3D space.

Problem

A user (Baruse) built an external FreeCAD script that hand-parses .qet project XML to extract conductor endpoints, then lets FreeCAD compute real-world wire lengths once elements are placed in 3D space. It works for the simple case, but the thread's own follow-up (plc-user) names the two things it can't handle: cross-references across multiple folios, and non-physical elements like jumps and splices. Baruse's own reply — "still in my mind, but now it doesn't work" — confirms these aren't solved, just deferred.

What exists today

• Every Conductor::toXml() (conductor.cpp:1040-1105) already writes each endpoint fully resolved — element1/element2 (parent element UUID), element1_label/element2_label (resolved actual label, formula already applied), terminal1/terminal2 (terminal UUID) and terminalname1/terminalname2 — so a conductor's electrical identity (which two named terminals it joins) is already unambiguous in the file. The external script re-derives this by parsing raw XML itself instead of being handed it directly.
• QET already ships a queryable per-project SQLite database specifically to back nomenclature/summary tables (projectDataBase, sources/dataBase/projectdatabase.cpp) — but its schema only has diagram, element, diagram_info, and element_info tables (projectdatabase.cpp:267-318). There is no conductor table at all. projectDataBase::addElement(Element*) (projectdatabase.cpp:112-141) populates the element side on every element add/edit; there's no equivalent addConductor().
• Folio cross-references already have a working, general solution for elements — XRefProperties (sources/properties/xrefproperties.h) plus AssignVariables::formulaToLabel() (used throughout assignvariables.cpp) resolve "where does the other end of this master/slave link live" across diagrams today. Conductors have no equivalent: a conductor's two terminals must both live in the same Diagram, so a wire that logically continues onto another folio (a "renvoi"/continuation, matched today only by convention — same label text on both ends) has no structured link the way element cross-refs do. This is exactly the gap plc-user flagged.
• "Jumps and splices" (a wire joining more than two conductor segments at a point with no element there) aren't represented anywhere in the object model — Conductor is fundamentally a two-terminal edge (terminal1/terminal2, conductor.h). There's no third category for an N-way junction node.

Proposed scope

Rather than trying to make QET aware of FreeCAD specifically, close the gap that's forcing every such external tool (this script, and any future one) to re-implement the same XML-parsing and folio-resolution work QET already does internally for elements:

• Add a conductor table to the project database, mirroring element/element_info: one row per conductor with both resolved terminal/element UUIDs, both resolved labels, and diagram UUID — same shape and same addElement-style incremental population, just for conductors instead of elements. This alone would let QetWireManager-style tools query a stable schema instead of hand-parsing conductor XML.
• Give folio-continuation wires a structured link, the same way element master/slave links already work — so "this wire's other end is really on folio 3, terminal X" becomes a queryable fact instead of an implicit label-matching convention external tools have to guess at. This directly addresses the cross-folio cross-reference gap named in the thread.
• Jump/splice (N-way junction) support is a bigger, separate modeling change — flagging it as a known related gap but explicitly out of scope here, since it would need genuine new geometry in the Conductor/Diagram object model, not just better data exposure.

Related, not proposed here

A native "export wire list" (CSV/table) UI feature, analogous to the existing nomenclature/summary table types, would be a natural consumer of the new conductor table once it exists — but the actual blocker for tools like QetWireManager is the missing structured data, not a missing export button, so that's proposed as the follow-up rather than the headline change.

Happy to build the conductor-table piece if the scope above sounds right.

[ispyisail]

Gathered into discussion #934, which writes up what exists today against current master and puts the open questions in one place. Continuing there rather than in three threads.