The scripting API (bugtracker #162) could place an element and move it,
and could count conductors but not make one. So a script could put a
coil and a motor on a folio and had no way to connect them, which is
most of what drawing is. This adds the missing verbs:
addConductor() wire terminal i of one element to terminal j of another
rotateElement()
setElementInfo() any information key
setElementLabel() the label key, by name, since it is the one people want
addFolio()
setFolioTitle()
elementUuids() what is on this folio
elementName()
elementTerminals() which terminal index is which, before wiring it
Each goes through the command the GUI already uses, so a script's edits
undo like manual ones and reach the project database the same way:
ConductorCreator (the drag-a-rectangle-over-terminals path, which is
what makes a new conductor inherit an existing potential's properties
and join auto-numbering), ChangeElementInformationCommand,
QETProject::addNewDiagram(), ChangeTitleBlockCommand. rotateElement()
pushes the same QPropertyUndoCommand on "rotation" that
RotateSelectionCommand pushes for an Element, rather than
RotateSelectionCommand itself, which works on the diagram's selection
and would mean rewriting the user's selection to rotate one element.
Terminals are addressed by index, not uuid. Terminal::uuid() is a
property of the catalog .elmt definition: empty for most of the
installed base, and where present, identical across every instance of
that element -- two coils of the same type placed side by side have
byte-identical terminal uuids, so a uuid cannot say which coil's A1 is
meant. elementTerminals() exists so a script can see the indexing
instead of guessing it.
The one real hazard is that ConductorCreator asks the user which
potential to inherit from when the two terminals sit on two different
existing ones, and it asks with a plain modal QDialog that
QET::QetMessageBox's non-interactive mode does not cover -- so under
headless --run there is nobody to answer and the call never returns.
Measured: with the check removed, that one call hangs until killed;
with it, it declines in 0.4 s. addConductor() therefore refuses that
case, the same way and for the same reason addElement() already refuses
the import-conflict dialog.
To make that check without duplicating the condition, existingPotential()
becomes static over an explicit terminal list and ConductorCreator gains
a public needsPotentialChoice() predicate. Behaviour of the GUI path is
unchanged; setUpPropertieToUse() passes m_terminals_list to the same code
it called before.
Verified headlessly against a copy of examples/ArduinoLCD.qet: new folio
titled, two coils placed, wired, labelled, an info key set and the
element rotated; saved, reloaded, and the conductor, label, title and
rotation (persisted as orientation="1") all read back. Re-saving the
result is byte-identical. qet-lint clean on the generated project;
qet-coherence-check clean on it and on the 24-project example corpus,
and shown to report 9 findings on a deliberately broken copy of the same
file, so the clean result discriminates. Qt 6.10.2, ctest identical to
master (the 61 failures are the vendored KDE ECM suite, present on both).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
PotentialSelectorDialog::chosenProperties() built an OK-only dialog
and discarded exec()'s return value entirely:
dialog.exec();
for (QRadioButton *b : H.keys()) {
if (b->isChecked()) return H.value(b);
}
return ConductorProperties();
Escape and the window close button already trigger QDialog::reject()
on a plain QDialog, but since the result was never checked, dismissing
the dialog without picking anything just silently returned blank
ConductorProperties() -- the same value returned when a real potential
was chosen but happened to produce empty properties. There was no way
to distinguish "the user cancelled" from "the user chose an empty
potential", so the caller always proceeded as if a choice had been
made.
Add a real Cancel button, check dialog.exec() == QDialog::Accepted,
and report cancellation through a new optional `bool *cancelled`
out-parameter. Also pre-select the first entry, closing a related gap
where clicking OK without ever touching a radio button hit the exact
same "silently returns blank properties" failure mode.
Thread the result through ConductorCreator::setUpPropertieToUse()
(now returning bool) so the calling constructor aborts and creates no
conductors at all when the user cancels, instead of proceeding with
blank properties.
The sibling constructor-based PotentialSelectorDialog (used for
conductor/report potential linking, a separate flow) already gates its
side effects behind on_buttonBox_accepted(), so cancelling it was
already safe -- gave it a visible Cancel button too for consistency
while touching this file, no behavior change there.
Verified with real Qt event simulation (QTest::mouseClick/keyClick)
against the exact new dialog-building logic: clicking Cancel and
pressing Escape both correctly report cancellation with empty
properties; clicking OK untouched returns the pre-selected first
entry; selecting the second option then OK returns that selection.
See discussion #581.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
clazy is a compiler plugin which allows clang to understand Qt
semantics. You get more than 50 Qt related compiler warnings, ranging
from unneeded memory allocations to misusage of API, including fix-its
for automatic refactoring.
https://invent.kde.org/sdk/clazy
ispyisail