Check the QLockFile in staleFiles() before returning a no-KF5 recovery candidate, matching the KAutoSaveFile contract that actively owned autosave files are not stale.
Extend the no-KF5 Catch test so a child process keeps the autosave lock alive while allStaleFiles() runs, then verify recovery after the child is killed.
Assisted-by: pi coding agent / Mika (OpenAI GPT-5.5)
Provide a small KAutoSaveFile-compatible implementation for the no-KF5 build path and use it to keep the existing crash-recovery code active when BUILD_WITH_KF5=OFF.
The normal KF5 build still uses the KDE KAutoSaveFile implementation.
Assisted-by: pi coding agent / Mika (OpenAI GPT-5.5)
The BUILD_WITH_KF5 option was checked with DEFINED, so passing -DBUILD_WITH_KF5=OFF still entered the KF5 setup path.
Skip the KF5 setup when disabled and provide small Qt-only replacements for the KDE color widgets used by .ui files in that build mode.
Assisted-by: pi coding agent / Mika (OpenAI GPT-5.5)
ProjectPropertiesDialog::exec() was using Qt::WindowModal, which only
blocks the parent ProjectView window. The MDI workspace and its other
subwindows remained interactive, so actions like new_project or
close_project could fire while the dialog's config pages still held raw
QETProject* pointers — leading to a SIGSEGV when Qt's event loop later
dispatched a signal through one of those stale pointers.
Detected by the 8-hour GUI fuzzer: action sequence add_diagram_page →
flood_wires ×18 → new_project while Project Properties was open
produced exit code -11 (SIGSEGV) on the first of 12,717 actions.
Switch to Qt::ApplicationModal so no window can receive input while the
dialog is open. Project Properties is a short-lived dialog; blocking
the whole application for its duration matches user expectation and
removes the lifetime hazard without requiring QPointer surgery across
four config-page classes.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The dock editor snapshotted the conductor once and never refreshed, so a
change made via the modal Edit-conductor dialog left the dock holding stale
values; on deselection apply() wrote that stale snapshot back, overwriting
the dialog's change. Subscribe to Conductor::propertiesChange and refresh via
updateUi() so the dock mirrors external edits and apply() becomes a no-op
when nothing changed in the dock.
Add English translations (qet_en.ts) for the new conductor-panel strings
so non-French users don't see untranslated source text: the panel title,
the two undo captions, the apply-to-all checkbox, and the View-menu
toggle + status tip.
The apply-to-all checkbox now reuses the modal dialog's exact wording
("Appliquer les propriétés a l'ensemble des conducteurs de ce potentiel")
for consistency and so it shares the existing translation.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Port the modal dialog's "apply to all conductors" option into the dock
panel, resolving the open propagation question. A persisted checkbox,
pinned above the tabs, makes each edit propagate to every conductor on
the same potential in one undo step - identical semantics to
ConductorPropertiesDialog, but the choice is remembered across edits.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Addresses the testing feedback on the conductor selection-properties
prototype:
1. Edits were never applied. The dock drives every editor through
setLiveEdit(true), which each editor overrides to connect its field
changes to apply(); ConductorPropertiesEditorWidget didn't override it,
so the call was a no-op. Implement setLiveEdit() to connect the hosted
ConductorPropertiesWidget's controls (commit-style signals) to apply().
A m_updating guard suppresses the signals emitted while the widget is
loaded programmatically, so a partial mid-load state is never committed.
2. Clicking a conductor's text label showed nothing, because the label is
a ConductorTextItem, not a Conductor. Map it to its parentConductor() in
the editor factory, mirroring the double-click-the-label dialog behaviour.
3. The panel sat at a small size hint with empty space below it. Give the
editor an Expanding vertical size policy (and a minimum height) so it
fills the dock like the other editors.
Refs #500
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
When a title block template uses custom variables (e.g. %{department},
%{owner}), the user previously had to declare each one by hand in the
folio properties 'Custom' tab before a value could be entered. Now the
template's undefined custom variables are added automatically, so the
user only fills in the values.
- listOfVariables() now extracts %{name} placeholders with a regex
(deduplicated) instead of a crude '%' strip that returned '{name}'.
- The folio properties widget merges the template's custom variables into
the Custom tab both on open (setProperties) and when the template is
changed, preserving any values already entered and skipping the
standard fields (title, author, date, ...) which have their own inputs.
Fixes#271 (variable auto-population; the revision-history request in the
thread is a separate feature).
Add a new boolean property 'showTerminalName' (default: true) to
XRefProperties, with full persistence in XML and QSettings.
A new checkbox "Afficher les numéros de bornes dans les Xrefs" is
added to the XRefPropertiesWidget in the main display group (not in
the cross-only group), so it is active in both Cross and Contacts modes.
When unchecked, terminal names are hidden in all three rendering paths:
- drawContact() (Contacts mode: NO/NC/SW symbols)
- fillCrossRef() (Cross mode: NO and NC columns)
- setUpCrossBoundingRect() (Cross mode: bounding rect sizing)
Backward compatible: existing project files without the attribute
default to showTerminalName=true (no visual change).
Files changed:
sources/properties/xrefproperties.h
sources/properties/xrefproperties.cpp
sources/ui/xrefpropertieswidget.ui
sources/ui/xrefpropertieswidget.cpp
sources/qetgraphicsitem/crossrefitem.cpp
Add a message box to advise user that use a hdpi round factor can cause
strange render according to :
1 - the selected value
2 - the dpi of the screen
3 - Edit the project on another computer and/or screen who don't have
the same parameters as point 1 and 2.
Laurent Trinques