mirror of
https://github.com/qelectrotech/qelectrotech-source-mirror.git
synced 2026-09-29 14:14:15 +02:00
ispyisail
0d08a4e265
Saving an unmodified project produced a different byte stream on every run: QGraphicsScene::items() returns items in stacking order, and ties between same-Z items follow the scene's internal index -- not any content-derived order -- so it isn't reproducible across process runs. The legacy terminal-id table inherits the same instability, since ids are assigned sequentially in element order. Sort list_elements and list_conductors into a deterministic order before serializing, using a key built from data that's actually stable across loads (position), not Element::uuid()/Conductor::uuid(): for an item with no persisted uuid attribute, fromXml() invents a fresh random one on every load, so sorting by uuid would still be non-deterministic across process runs for any legacy file -- which this corpus has plenty of. Also fixes a second, related source of byte-level non-determinism found while verifying the above: Conductor::toXml() unconditionally wrote m_uuid back out, including the synthetic value fromXml() just invented for a conductor with no uuid attribute in the file. Every conductor in every example project checked has no persisted uuid at all, so this alone meant no project with conductors could ever resave identically, regardless of ordering. Conductor gets a m_persist_uuid flag, false only when the uuid it's holding was synthesized rather than loaded, so toXml() stops writing a value that was never meant to be permanent. Deliberately NOT applying the same uuid-persistence fix to Element: element uuids are cross-referenced by other elements' <links_uuids> blocks for master/slave/report linking (element.cpp, tmp_uuids_link, matched by elmt->uuid() == stored uuid on load). Making an element's own uuid non-persistent would silently break that match for any linked element without one already -- a real regression, not a theoretical one. Left as a smaller, separate residual: 1-6 elements per project across the corpus (a few tenths of a percent) still get a fresh uuid on each load, same class of bug, needs the link-aware version of this fix instead of this one. Verified against 8 example projects (the ones with conductors, plus the two zero-conductor control cases from FINDINGS.md F002), 5 resaves each in isolated HOME/XDG environments: - Element and conductor ORDER: 0 churning sections across the whole corpus (previously the majority of diagrams in industrial.qet, m_000.qet and tremie_vibrante.qet churned on every run). - Conductor uuid VALUES: 0 churn (previously every conductor in every project, since none have a persisted uuid). - 6 of 8 projects are now byte-for-byte identical (md5) across all 5 runs. The remaining 2 (industrial.qet, m_000.qet) differ only in the handful of element uuids covered by the known Element residual above -- confirmed by checking those uuids specifically, not inferred. - Element/conductor counts before and after resave match exactly on every project (no data loss from the sort). Fixes #754.