mirror of
https://github.com/qelectrotech/qelectrotech-source-mirror.git
synced 2026-09-27 20:44:13 +02:00
ispyisail
a8f883601d
titleBlockTemplates() embedded + common/company/custom, by name embedTitleBlockTemplate(name) copy one into the project's own collection setFolioProperty(f,"template",name) embed-if-needed, then apply folioProperty(f,"template") Not the trivial addition to the existing title-block-field list it looked like at first. Diagram::setTitleBlockTemplate() resolves a name only against QETProject::embeddedTitleBlockTemplatesCollection() -- the exact same copy-into-the-project step addElement() already goes through for elements, and for the same reason: a project opened on another machine must not depend on files only this one has. embedTitleBlockTemplate() does that copy through get/setTemplateXmlDescription(), the same round trip the template editor itself uses to save one -- not scripting-specific code, and unlike defining an auto-numbering context, not undoable, for the same reason that isn't: the application does both through direct collection/project calls with no undo command of their own. Two things found only by testing, not by reading: - "default" is a real template name in the common collection, and setting a folio's template to it is legitimate -- but BorderTitleBlock::titleBlockTemplateName() normalises a template literally named "default" back to "", indistinguishable from no override, since that is genuinely what "no override" renders with. The first version compared the raw name and reported success as failure; fixed by comparing against that same normalised form, which folioProperty() now also documents. - QElectroTech resolves the common template collection from a compiled-in path (here, an absolute /usr/share/qelectrotech/titleblocks, not relative to the binary), and --common-tbt-dir, the CLI override, is read by QETApp::parseArguments() -- which the --run headless path never reaches, confirmed by the CLI itself swallowing the flag as a stray positional argument. There is no QSettings fallback the way commonElementsDir() has. So testing this at all needed the path to genuinely exist; no environment trick from inside the process reaches it. Verified: 10 common templates listed; DIN_A4 embedded and applied, folioProperty reading it back; re-applying the same name a no-op success; an unknown name refused; "default" applied and correctly read back as "" per the note above; both folios exported to PNG and visually compared -- plain default rendering vs. DIN_A4's logo, revision table and field layout, genuinely different, not just an API call returning true. The choice survives a save and reload. Qt 6.10.2, ctest 12/12, coherence gate clean. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>