mirror of
https://github.com/qelectrotech/qelectrotech-source-mirror.git
synced 2026-09-28 04:54:13 +02:00
ispyisail
5b8d05fc1e
Slice 4 of discussion #503, on top of slice 3 (#629): the smallest surface that makes wiring_list_view visible, plus the diagnostic the view needs to be honest about what it is missing. Projet > "Liste de câblage (base de données)" opens a read-only table of wiring_list_view, headed by a line stating how many conductors are listed and, when non-zero, how many were excluded and why. Deliberately not another exporter. QET already ships a wiring-list CSV export (Projet > Exporter le plan de câblage, and --export-cables) which walks the project XML; measured on the same projects it produces a row per conductor and resolves labels correctly when the project has them. Adding a second, competing CSV would be worse, not better -- the database path's value is what it unlocks (terminal plans, BOM joins), not replacing that export. projectDataBase::excludedConductorCount() counts, from the live scene, the conductors deliberately absent from the conductor table because a terminal has no uuid. Counted from the scene precisely because the database is where those conductors are not. Verified: 671 on examples/industrial.qet (which has 1794 terminals and no terminal uuids at all, so its list is empty and now says so), 0 on a project whose elements do carry terminal uuids. KNOWN GAP, not fixed here and the reason this is opened for discussion rather than merge: after a save/reload the component columns are blank for slave elements. populateElementTable()/populateElementInfoTable() only insert Simple|Terminal|Master|Thumbnail, so slave elements -- relay contacts, i.e. a large share of real wire endpoints -- have no row in element_info for the view to read a label from. Measured on a two-slave- contact project after reload: element rows 0, element_info rows 0, terminal rows 2, conductor rows 1; the wire is listed (slice 3's LEFT JOIN keeps it) but both component names are empty, where the existing CSV export shows K1 -> K2 for the same file. Closing that gap means widening a filter shared with the nomenclature and summary views, which would change what those existing, shipped features contain. That is a maintainer decision, not one to take unilaterally inside an additive slice.