Five things raised in review, plus tests for the parts that were only
described in prose.
clearPendingCrashDump() did not do what its comment said. It called
pendingCrashDumpFiles() again at clear time, so it deleted whatever was
in the directory then, not what had been offered. The offer sits inside a
modal dialog that stays open as long as the user reads it, and
SingleApplication keys its socket on the binary path, so a second
QElectroTech build running alongside is a separate process that can crash
and write a dump in that window. Re-listing deleted that dump unseen --
the exact failure this change exists to fix. The list is now taken once
in QETApp::checkCrashDump() and passed to both
pendingCrashDumpContents() and clearPendingCrashDump().
The ring is now written before the backtrace. backtrace() unwinds through
libgcc, which calls dl_iterate_phdr and takes the loader lock; warming it
in install() removes the allocation but not the lock. Crashing inside
dlopen() (Qt plugin loading), or on a corrupted stack, could therefore
hang or re-fault the handler at the backtrace and lose the ring with it.
Order is now header, signal, ring, backtrace, so the cheapest and most
valuable part is already on disk before anything that can block. The
class comment claimed the handler takes no locks; that was not strictly
true and now says so.
QET_CRASH_BACKTRACE comes from find_package(Backtrace) rather than
__has_include(<execinfo.h>). The header exists on FreeBSD but backtrace()
lives in libexecinfo there, so the probe compiled and the link failed.
A crash_dump.log left by a pre-#905 version is migrated into crashes/ at
startup, named from its own mtime. Otherwise upgrading stranded it: the
new code never looks at that path, so the dump from the crash that
prompted the upgrade would sit there unoffered forever.
Also from the review: dumps are capped at the 10 newest, so a crash loop
cannot fill the log directory before any dialog is shown; crashDumpDir()
no longer creates the directory as a side effect of a const getter
(ensureCrashDumpDir() does that for the callers that write); and redact()
now masks an AppImage's per-run /tmp/.mount_XXXXXX prefix, which
backtrace_symbols_fd() writes into every frame.
Two test executables, both of which were checked to fail against the
behaviour they replace:
- tst_crashhandler covers CrashHandler::formatInt(), which had no
coverage at all despite running only inside a signal handler, where
nothing can assert: zero, negatives, INT_MIN (negated through unsigned,
since -INT_MIN is UB), INT_MAX, truncation and a zero-sized buffer,
each checked against a sentinel-filled buffer so a write past the
reported length fails.
- tst_crashdumps covers the bookkeeping: ordering, empty dumps, the
exclusion of this run's own path, the cap, concatenation of every
offered dump, that clearing deletes only what was offered, and what
redact() masks. qetlogger.cpp needs exactly one symbol from the
application, QETApp::dataDir(), which the test supplies itself.
Not addressed here: the timestamp in crash_<timestamp>_<pid> is the
launch time, not the crash time -- correct as observed, and the commit
message that implied otherwise was the thing that was wrong. Resolvable
QET frames for AppImage/Flatpak/Snap/Debian need -rdynamic and archived
debug symbols, which is a packaging discussion, not this change.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Save and restore the state of m_component_info_cb, m_fit_in_page_cb,
and m_use_full_page_cb via QSettings, in addition to the existing
ExportProperties-based checkboxes (border, titleblock, terminals, etc.)
- Add savePrintProperties() to persist all checkbox states after
print/export under the "print/default" settings prefix
- Remove unused QPrinter(HighResolution) local variable in launchDialog()
that caused an unnecessary ~2s CUPS round-trip on Linux
Fix multiple issues introduced by commit 55c2c0df9 (interactive paste):
Paste placement (diagrameventaddpaste):
- Items now load at their original XML coordinates instead of being
snapped to the cursor position, preventing jumps on initial placement
- Use delta-based movement: record the actual grid-snapped cursor
position on first mouseMoveEvent as baseline, then compute
grid-snapped deltas from there
- Bypass Diagram::snapToGrid() in moveTo() to avoid Ctrl modifier
causing pixel-snapping instead of grid-snapping
- Remove moveTo() from mouseReleaseEvent to prevent a final jump
on click
- Warp cursor to group bounding rect origin for visual feedback
Paste command (diagramcommands):
- Always clear PLC slave data (type, address, function, comment,
cross-ref, label, TC, T1-T4) on paste regardless of the
erase-label-on-copy user preference
- Block alignment (m_block_alignment / blockAlignmentUpdate) before
setElementInformations() for both slaves and non-slaves, preventing
finishAlignment() from shifting right/center-aligned text items
- Clear non-UserText items directly after setElementInformations()
for slaves as a safety net
openAndAddProject() shows BackupDialog as a stack object parented to the
editor and exec()s it; every QET::QetMessageBox does the same. exec() runs a
nested event loop, and closing the editor during it turns WA_DeleteOnClose
into a deleteLater() that the nested loop processes: ~QWidget() deletes the
editor's children, the stack-allocated dialog among them, and the process
aborts. Reported on macOS, where File > Quit lives in the application menu
and stays usable while the backup question is up.
The close is now refused while any modal widget is active, and the dialog is
raised so the refused quit is not silent. It is done in QETMainWindow::event()
rather than in closeEvent(), because QETDiagramEditor::closeEvent() starts
closing projects before it decides whether to accept. That covers the diagram
and title-block editors; QETElementEditor is a plain QMainWindow, so its
closeEvent() calls the same helper before canClose(), which itself opens a
modal. QETApp::quitQET() needs nothing: closeEveryEditor() goes through each
editor's close(), and quitQET() already only quits when every close succeeded.
Rejected alternatives, both suggested on the issue:
- Giving the dialog no parent stops the abort but not the deletion. One
caller of openAndAddProject() is the editor's own constructor, which goes
on to open the next file and call slot_updateActions() on this -- a loud
abort would become a silent use-after-free.
- Guarding only QETApp::closeEveryEditor(), which I first recommended on the
issue, misses the reported route entirely: File > Quit is connected to
QETDiagramEditor::close(), not to quitQET().
Verified on Linux, where there is nothing to click (the menu bar belongs to
the blocked window, and Qt ignores window-manager close requests for it), by
calling close() from gdb while the dialog's loop was running -- both
QETApp::quitQET() and QWidget::close() on the editor. Unfixed, both abort
with "free(): invalid size" in QObjectPrivate::deleteChildren() under
~QETDiagramEditor(), matching the report frame for frame; fixed, close()
returns false, the editor and the dialog stay up, and after answering the
dialog Ctrl+Q exits normally. The element-editor guard is the same helper
but was not exercised separately.
tests/modal-quit-regression/ turns that into a gate: it breaks on
QDialog::exec(), interrupts inside the nested loop, calls quitQET() and
checks the process survives. It matches no window titles (translated) and no
window ids, runs on the offscreen platform, and needs only gdb with Python.
Checked both ways: exit 1 with the backtrace above on a build without this
change, exit 0 with it.
ctest 8/8.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
When duplicating a diagram page, copied slave elements retain stale
data from the source: labels, descriptions, link references, and PLC
master information (type, address, function, comment, cross-ref, timer
values) remain in the copies.
Fix by adding clearPendingLinks() to Element to prevent copies from
linking back to source elements via stale UUIDs, and by cleaning up
copied element data after fromXml():
- Slaves always lose their label, formula, comment, location, and
PLC master data, since their text comes from a master element which
is not available on the copy. The displayed text on slave elements
is cleared directly via setPlainText(), but UserText items (free
text typed by the user) are preserved.
- For PLC slaves, setElementInformations() is called without
m_block_alignment so that elementInfoChanged() can run
finishAlignment() to correctly adjust text positions for the
cleared content.
- Non-slave elements respect the existing erase-label-on-copy
preference, same as PasteDiagramCommand::redo().
- Conductor labels are also reset when erase-label-on-copy is
active, matching PasteDiagramCommand::redo() (issue #413).
- Text alignment is preserved by wrapping setElementInformations()
with m_block_alignment for non-slave elements, same as
Element::fromXml().
Three weaknesses, all visible in ChuckNr11's report on #898 -- "the report
appeared only once despite there being 10 or more crashes".
One dump per run instead of one per install
-------------------------------------------
crashDumpPath() was a single fixed crash_dump.log, and the handler opens it
O_TRUNC, so each crash destroyed the evidence from the one before. Ten
crashes left one dump. Dumps now go to a crashes/ directory named
crash_<timestamp>_<pid>.log, and every pending one is offered together,
newest first, with a banner saying how many there are. A crash that repeats
is exactly the case where the earlier dumps matter, because the difference
between them is the evidence.
The name is built in normal context and handed to CrashHandler::install(),
which copies it into a preallocated buffer as before -- the handler still
writes to one fixed path, so its no-allocation invariant is untouched.
The dump now says which signal fired
------------------------------------
The header is built once at install(), so every dump looked identical no
matter what killed the process -- and SIGSEGV and SIGABRT point at very
different bugs. Written with an async-signal-safe integer formatter into a
stack buffer, since snprintf is not on the POSIX safe list.
...and where it was
-------------------
The ring said what the program was doing; nothing said where it died. The
dump now carries a backtrace. backtrace() is warmed once in install() so
its first-call lazy resolution cannot allocate inside the handler, and
backtrace_symbols_fd() writes straight to the fd -- unlike
backtrace_symbols(), which mallocs and must never be used here. Guarded on
__has_include(<execinfo.h>) so platforms without it are unaffected.
QET's own frames currently resolve as offsets rather than names, since the
binary does not export its dynamic symbols. They are still resolvable
offline: the header records the exact git SHA. Building with -rdynamic
would give names directly, but that is a build-flag decision for its own
change.
Deliberately unchanged: the four invariants in crashhandler.h. Nothing
added here allocates, blocks, takes a lock, or swallows the crash.
Verified: three consecutive SIGSEGVs now leave three separate dumps, each
carrying "Signal: 11" and a backtrace with resolved Qt frames; launching
afterwards offers all three in one dialog, newest first, and clears them
once shown. ctest 8/8.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
QET had no icon theme: the 446 entries of the icon table and the 116
iconsets in .ui files each named a resource path, so an icon could only
ever be one file, and a variant for another palette or a vector source
had nowhere to go (GitHub #466, #690, #870). This adds the theme layout
without changing a single pixel; a dark variant comes in a follow-up.
The theme "qet" follows the freedesktop layout Qt's icon loader
understands. misc/make_icon_themes.py generates ico/icon-themes.qrc,
which aliases the existing ico/<size>/<name>.png files into
themes/qet/<size>/<name>.png, and ico/themes/qet/index.theme. No file
moves. The four table entries that paired a 16 pixel file with a 22
pixel file of another name (ConductorSettings, DiagramAdd,
DiagramDelete, DialogInformation) get the 22 pixel file aliased under
the 16 pixel name.
QETApp::initIconTheme() registers the theme before initIcons() and makes
it current on every platform, so a desktop icon theme cannot replace
QET's icons. Icons are then looked up by name: QIcon::fromTheme() in
qeticons.cpp and in the few places that built a QIcon from a resource
path directly, and theme="..." on the iconsets in .ui files, with the
resource path kept as fallback. Flags, color swatches, application and
MIME icons stay on their paths.
One entry does not go through the theme. The elements panel draws the
project root with ProjectFileGP in the 50 pixel slot it reserves for
element previews, and the name "project" also carries the 128 pixel
file the configuration dialog uses. On a 2x display Qt's loader picks
that file for a 50 pixel request and fills the slot. ProjectFileGP
loads the 16 and 22 pixel files directly, as before.
tests/qttest/tst_qeticons: every name in the theme resolves, the four
aliases resolve at 22 pixels, a Fusion tool button shows its icon at
3:1 with disabled weaker than enabled, and the project root icon stays
at 22 pixels or less when asked for 50 at 2x while the configuration
dialog still gets its 128 pixel file. The rendering helpers shared
with tst_qetpalette moved to tests/qttest/inkcontrast.h.
QETApp::checkBackupFiles() only reached checkCrashDump() when there was
nothing to recover:
if (stale_files.isEmpty()) {
checkCrashDump();
return;
}
A crash with a project open always leaves a stale KAutoSaveFile, so on the
next launch the recovery prompt won every time and the dump sat on disk
unoffered -- the report was unreachable in exactly the case it is most
wanted. Reported by ChuckNr11 as a side note in #898: "the report appeared
only once despite there being 10 or more crashes". It appears on the runs
that happen to have nothing to recover.
Discussion #644 step 5 asks that the two prompts never show at the same
time, which this keeps: the recovery prompt is answered first, then the
report. The recovery half moves into offerBackupFiles() so both paths fall
through to the same place.
Verified under Xvfb, from a real crash state (SIGABRT with a project open,
leaving both a stale file and a 5.4 KB crash_dump.log): the recovery prompt
appears, and dismissing it now brings up "Rapport de plantage" carrying the
version, git SHA, OS, Qt version and the log ring. Before this change the
report never appeared -- that half rests on the four lines above rather
than on a captured before/after, since re-creating the crash state for a
clean baseline run kept consuming it.
Not addressed: the dump is a single fixed path opened O_TRUNC, so
consecutive crashes still overwrite one another.
ctest 8/8.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
a) paste
- conductor does not move
- pressing escape does not abort
- pressing anything during the process crashes the program instead of aborting
b) similar issue with the escape not working fixed for graphics items, texxt fields (and probably others)
Refs discussion #886: a saved-report manager built on custom SQL and
nomenclature.json. Most of what was asked for already existed --
Projet > Exporter au format CSV already builds/saves/reuses named
SELECT queries via ElementQueryWidget and nomenclature.json, and
Projet > Ajouter une nomenclature already inserts one into a folio.
This fills the three real gaps.
- projectDataBase::isReadOnlySelect() rejects anything that isn't a
single SELECT/WITH statement. Checked in newQuery() itself, the one
choke point every query path already goes through -- including a
query loaded from a saved nomenclature/summary table's <query>
element on project open, not just the dialog's own custom-SQL box.
ElementQueryWidget shows the same check live as you type, and
BOMExportDialog surfaces it before running or exporting anything.
- BOMExportDialog gains a Preview button + table (QSqlQueryModel),
so a report can be checked on screen before committing to a CSV file.
- ElementQueryWidget gains Importer.../Exporter... buttons that
read/write nomenclature.json's saved reports as a JSON file, so a
report can be handed to a colleague or another install. Import asks
before overwriting a locally-saved report of the same name.
Verified: Qt 6.10.2, builds clean, ctest 8/8. Drove the real dialog
through Xvfb: typed "DROP TABLE element" into the custom-SQL box and
got the inline warning immediately, then confirmed Preview also
refuses it with a "Requête refusée" dialog rather than running it.
Preview against the real default query returned live column headers
and a row. Export opens a save dialog without crashing.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Another exception: one non-converted code path in projectprintwindow.cpp to be followed-up.
One issue found in the Qt6 code path of diagramview.cpp which has been fixed.
Addresses scorpio810's review of PR #890 (bugtracker #734):
- The four cas "3"/"4" bridge-skip guards now compare qRound()ed
coordinates, matching how the bridge coordinate itself is computed --
an exact != would miss a pair already grid-equal after rounding but
off by a sub-pixel remainder, and still route a degenerate bridge for
it. Verified no behavior change on the shipped corpus: per-file
self-retrace counts are identical before/after (every coordinate
there already lands exactly on-grid).
- Added tests/qttest/tst_conductorselfretrace.cpp, fixture
qet_bug_repro_resaved.qet (the report's own canonical reproduction):
exports it via the built binary's --export-svg and asserts no
conductor path is self-retracing. Confirmed it actually catches the
regression, not just passes vacuously -- reverted conductor.cpp to
master and reran: fails, 1 self-retracing path found.
Not changed in code: the cas "4" descending-branch dead-code note (kept
for symmetry, as already agreed) and the schema_unifilaire_voltaique2.qet
trade-off (flagged for the reviewer's own visual check).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Addresses scorpio810's review of PR #891:
- addElement() now imports the element into the project's own embedded
collection first (QETProject::importElement()), same as the
drag-from-collection-panel path -- otherwise the saved .qet referenced
a definition outside the project, missing on another machine. Also
found and fixed while wiring this up: ElementsLocation::setPath()
forces any path to embed:// once a non-null project is passed, so the
unconditional ElementsLocation(locationPath, m_project) this method
used before silently broke every common://custom:// call. Refuses
on an import-collision case that would otherwise reach
QETProject::importElement()'s own modal ImportElementDialog, with
nobody there to answer it in a script.
- addElement()/setElementPosition()/moveElement()/deleteElement() refuse
on a read-only project, matching their GUI equivalents.
- save() goes through QETProject::write() when no path is given (read
-only handling, saveddate/savedtime, QSaveFile via writeXmlFile()) and
QET::writeXmlFile() directly for an explicit output path, instead of a
plain QFile that skipped all of that.
- Interactive "Run Script...": exports briefly disable project backups
around the temporary QETProject CLIExport::run() opens on the same
file, so it doesn't race the real open project's own KAutoSaveFile.
Restored right after -- the headless --run path is untouched, since it
depends on backups staying off for the whole run.
- A watchdog thread now calls QJSEngine::setInterrupted() after 30s,
so a runaway script (`while(true){}`) can't freeze the GUI or hang a
CI job forever. First version used sleep_for() and blocked every run,
fast ones included, for the full 30s on join() -- caught by testing a
one-line script, fixed with wait_for() on a condition variable so a
script that finishes early wakes the watchdog immediately.
- Interactive script errors now also show a QetMessageBox, not just
stderr (invisible on Windows).
- Ran update_translations (lupdate) to pick up the 37 strings this
feature had not yet added to the .ts files.
Not applied: wrapping the whole script run in one undo macro. It would
make the script's own qet.undo()/qet.redo() calls silent no-ops for the
run's duration -- QUndoStack ignores undo()/redo() while a macro is
open -- which would break that already-shipped, explicitly requested
capability to get one convenience Ctrl+Z instead.
Verified: Qt 6.10.2, builds clean, ctest 6/6. Ran each fix against a
real project: addElement() on a common:// path now succeeds and the
saved file embeds the definition (embed://import/...); read-only
project refuses addElement(); save("") and save(otherpath) both
produce a correctly embedded file; `while(true){}` under --run is
interrupted at 30s where it previously hung forever, and a normal
script now exits in ~0.3s instead of blocking for the full timeout
budget.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Add !parentGroup() guard to stale xref removal in updateXref()
to prevent deleting xref data that ElementTextItemGroup::updateXref()
just stored for a grouped text item.
- Replace QStringLiteral("xref") with QETInformation::ELMT_XREF
in linkelementcommand.cpp and masterelement.cpp.
- Fix indentation in plclinkwidget.cpp.
The Selection properties "texts" tab painted the color value's own text in
that color, so the default black was unreadable on a dark palette. Show a
swatch in the cell instead and leave the text in the palette's color.
The terminal plan preview draws black ink with a white brush, like the
printed page it previews, on whatever background the view inherits from
the palette. Give the view a white background.
main.cpp has forced the Fusion style on macOS since 2019, but the palette
still came from Qt's macOS platform theme, which is built for the native
style. It hands Fusion a Window, Button and Base that are the same color,
a Dark lighter than Light, and in dark mode an Inactive ButtonText of
black. Fusion derives its frames, gradients and indicators from those
roles, so fields had no edges, the radio buttons in the text alignment
dialog vanished, and the "Handles" combo box in the diagram editor
toolbar drew its text black on a dark combo the moment the window lost
focus. Light mode had the same flatness, with Window, Button and Base
all white.
Add QET::Palette (sources/qetpalette.{h,cpp}) with a light and a dark
palette laid out the way Fusion expects, and install one from
QETApp::initStyle() on macOS when the running style is Fusion, choosing
by the platform palette's lightness and keeping the platform's accent
color when it reads at 4.5:1. On macOS the base palette is now applied
whether or not "use system colors" is checked, since the system palette
cannot be drawn by Fusion; that setting only decides whether style.css
is layered on top (#467). On Qt 6.5+ the app follows the OS light/dark
switch through QStyleHints::colorSchemeChanged.
Other platforms are untouched: Fusion is Qt's default style on Linux
desktops without a platform theme, and the palette there carries the
user's desktop colors. Making Fusion and this palette the default
everywhere is discussed in #870.
tests/qttest/tst_qetpalette checks every text role pair at WCAG 4.5:1
(3:1 disabled), that Inactive equals Active, and paints a Fusion combo
box, radio buttons, buttons and a line edit on the offscreen platform to
measure the ink against its background. Set QET_TEST_DUMP_DIR to keep
the rendered images.
- Element::reloadPicture() now returns a ReloadPictureResult and never
clears the current drawing before a successful rebuild: a missing or
unreadable definition leaves the element as it was instead of blank.
- Elements whose size, hotspot or terminals (added, removed or moved)
differ from the new definition are not redrawn: the new drawing would
no longer match their bounding rect and live terminals.
- The action lists those elements and warns that they must be removed
and re-inserted, which deletes the conductors already connected to
them.
- Status tip states the action is not undoable.
Terminal::~Terminal() called qDeleteAll(m_conductors_list) on the live
member. Each Conductor destructor calls removeConductor() on both of its
terminals, and that removes the conductor from the same list qDeleteAll
is iterating. Mutating a QList while iterating it is undefined
behaviour; with two or more conductors on one terminal (terminal strips,
bridged terminals) it can skip a delete or delete one conductor twice,
which leaves another conductor's terminal1/terminal2 pointing at freed
memory.
The pattern dates from a00404bc9 (2021), which replaced a foreach loop
(iterating an implicit copy) with a direct qDeleteAll. It went unnoticed
until the deterministic sort keys added to Diagram::toXml() in #844
started reading pos() on both terminals of every conductor on every
save, including the periodic backup, which turned the stale pointer into
an EXC_BAD_ACCESS in QGraphicsItem::pos() while deleting an element.
Copy the list first and delete from the copy, restoring the pre-2021
behaviour. An isolated regression test (a hub terminal with 2 to 8
conductors, under AddressSanitizer) did not trigger the failure with the
old code, so none is included; the crash analysis and that attempt are
recorded in jp2images/qelectrotech-source-mirror#1.
LineEditor::setPart() no-ops (skipping updateForm()) when the part
passed in is already m_part. That is harmless when the editor widget
is torn down between selections, but this branch keeps the same
editor instance installed across selection changes instead of
recreating it, so a line already shown alone can also be
parts.first() of a later multi-selection -- and the x1/y1/x2/y2
spinboxes then keep showing whatever was in them before, not this
selection's actual first line.
setParts() now always calls updateForm() after setPart() succeeds,
closing the gap regardless of the identity check inside setPart().
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Extends the scripting surface from the previous commit with exactly
the three things explicitly scoped out there, per follow-up direction:
editing geometry, undo integration, and driving the GUI -- the last
one narrowed to select/zoom/message after discussion, since "invoke
any menu action by name" would let a script trigger a modal
QDialog::exec() with nobody there to dismiss it, the same hang class
investigated for bugtracker #882.
## New capabilities
- addElement/setElementPosition/moveElement/deleteElement, through the
same undo commands the GUI itself uses: AddGraphicsObjectCommand
(the same one drag-from-collection-panel placement uses),
QPropertyUndoCommand on the standard `pos` property, and
DeleteQGraphicsItemCommand (refuses a non-deletable terminal, same
as the Delete key).
- undo/redo/canUndo/canRedo against the project's real QUndoStack --
the same one QETDiagramEditor's Ctrl+Z is wired to via
undo_group.activeStack(), not a parallel mechanism.
- selectElement/deselectAll (scene state, no view required -- works
headless), zoomFit/zoomToContent/zoomReset (need the active
DiagramView, so false headless where there is nothing to zoom), and
showMessage (a modal QET::QetMessageBox::information -- safe headless
because non-interactive mode is already on for the whole process
before any script runs).
## Two real bugs caught by testing this, not assumed away
1. save() was still going through the same reopen-from-disk path as
every export method: it opened a *second*, unmodified copy of the
project from its file on disk and rewrote that. addElement() and
friends operate on the live in-memory project, so nothing they did
ever reached the saved file -- an element counted correctly in
memory and then silently vanished from the output. Fixed by having
save() write m_project->toXml() directly, the only method that
touches the live instance rather than a fresh copy of the file.
2. A script calling setElementPosition() then moveElement() on the
same element produced a saved position that didn't match either
call, and undo/redo didn't step through them independently. Traced
to QPropertyUndoCommand::mergeWith() (pre-existing, not new):
consecutive commands on the same object+property merge when their
text() also matches, and both calls build the identical "Déplacer
%1" text for a given element -- exactly the same collapsing
dragging an item repeatedly gets. Not a bug in the new code; a
wrong assumption in the first test. Re-verified against the
correct, merge-aware expectation: add -> merged move -> undo (back
to first position) -> undo (element removed) -> redo (element back)
-> redo (merged move reapplied) landed at the exact predicted final
position, read back from the saved XML.
## Verified
Qt6, build clean from a fresh reconfigure, ctest 6/6.
- Headless: addElement returns a real uuid and the count updates;
select/set-position/move all report correctly; the merge-aware
undo/redo/save round trip above, confirmed against the saved file's
actual XML, not just in-memory counters.
- Corpus: the existing read-model smoke script re-run against all 24
shipped example projects on the fixed binary, 0 failures.
- zoomFit correctly returns false headless (no view to act on),
confirming the "narrowed GUI-driving" scope holds in code, not just
in the doc comment.
- GUI: running the add-only script via "Exécuter un script..." marked
the project [modifié] in the title bar, the same change-tracking
path a manual edit goes through -- consistent with the undo command
actually being pushed onto the project's real stack rather than some
side channel invisible to the rest of the application.
Refs #162.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Following up on my own comments there: a deliberately small, mostly
read-only scripting surface, exposed to scripts as a single global
`qet` object (QetScriptApi) built on QJSEngine rather than an embedded
Python interpreter -- no new toolchain to package (QJSEngine ships in
every Qt SDK QET already targets, via the Qml module), no GIL, no
version pinning, automatic reflection of the QObject-derived core
classes' own methods with no hand-written binding layer.
## What a script can do
- Read the model: project title, file path, folio count/titles,
element/conductor counts per folio.
- Trigger the same operations the --export-* CLI flags already do
(pdf/png/svg/cables/wires/bom/wiring/nets/links/info), plus
set-titleblock and save -- thin wrappers around CLIExport::run(),
reusing its already-tested logic rather than duplicating it.
Deliberately NOT in this version: creating or editing diagram
geometry, undo integration, driving the GUI. All explicitly out of
scope per the discussion on #162.
## Two entry points, both built and tested
- `qelectrotech --run script.js project.qet` -- headless/CI.
- Projet > "Exécuter un script..." -- an interactive macro against the
currently open project. Export/save calls act on the project's file
on disk (see QetScriptApi's class comment for why), so unsaved GUI
edits aren't visible to the script; save first if that matters.
## Optional dependency, not a hard requirement
Qt::Qml is probed the same way QtPdf already is in this codebase:
QUIET, non-fatal, behind a QET_HAS_SCRIPTING compile definition. A
build without it compiles and links identically; the CLI flag and
menu action are simply absent (main.cpp) or compile to a clear
"not available" stderr message rather than silently disappearing
(qetscripting.cpp), matching the existing QtPdf pattern rather than
introducing a new one.
One real bug caught building this, not assumed away: my first pass
conditionally excluded the new source files from QET_SRC_FILES behind
`if(QET_HAS_SCRIPTING)` inside qet_compilation_vars.cmake -- but that
file is included before QET_HAS_SCRIPTING is set in the top-level
CMakeLists.txt, so the variable didn't exist yet at that point and the
files were silently never compiled, only caught by an undefined-symbol
link error. Fixed by following the QtPdf file's own precedent:
compile the files unconditionally, guard their Qt::Qml-dependent
content internally instead.
## Verified
Qt6, build clean, ctest 6/6.
- Headless: a script reading project/folio/element/conductor counts,
calling exportInfo() and exportPdf() against a real project --
correct JSON, a real single-page PDF confirmed with `file`.
Error paths: a thrown script exception reports file:line:message and
exit 1; missing script/project arguments exit 2 (matching
CLIExport's own usage-error convention); a missing project file is
reported and does not hang.
- Corpus: the same read-model script run against all 24 shipped
example projects, 0 failures.
- GUI: "Exécuter un script..." opens a real file dialog filtered to
*.js, running the picked script against the live open project
produced the exact expected JSON export file, and the application
was still fully responsive afterward.
Refs #162.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Laurent Trinques