https://qelectrotech.org/bugtracker/view.php?id=335
## Bug
Element library icons (collection tree thumbnails, drag icon, preview
panels) render with a fully transparent background. Element definitions
almost always hardcode a black stroke color, on the assumption of the
white diagram sheet they are normally drawn on. Against a dark widget/
tree-view background (e.g. KDE Plasma dark theme), that black stroke
disappears entirely - reported as icons being "black and almost
invisible". scorpio810_mantis linked this to the same recurring family
as #231, #247, #267.
## Fix
ElementPictureFactory::pixmap() is the single shared point where every
consumer of these icons gets its QPixmap (collection tree via
ElementsCollectionCache -> Element::pixmap(), master/slave properties
tree, element properties preview, drag icon). Change its background
fill from fully transparent to opaque white - exactly what the element
already visually assumes in every context this pixmap is used, so it
is correct regardless of the surrounding widget's palette.
## Testing
Built both variants and compared under Xvfb using a simple, decisive
visual test: select the tree row (giving it a highlighted/colored
background) and compare what shows immediately around the icon's
glyph.
- Before: the icon's background matches the row's selection color -
confirms it is transparent, so on a dark unselected row the black
strokes would have the same problem.
- After: a solid white square is visible behind the glyph regardless
of the row's background color.
Note for the on-disk pixmap cache used by ElementsCollectionCache
(~/.local/share/QElectroTech/QElectroTech/elements_cache.sqlite):
existing cached PNGs predate this fix and will keep their transparent
background until regenerated. That cache already keys strictly on
path+uuid with no invalidation on QET version, so this is an existing
characteristic of that cache, not something introduced here.
Bugtracker #291: clicking Cancel on the open/save-element dialog before
the user collection finishes loading crashes the whole application with
an unhandled pointer exception.
ElementsCollectionModel::loadCollections() loads collections in the
background via QtConcurrent::map(m_items_list_to_setUp, setUpData) -
worker threads call setUpData() on each ElementCollectionItem
(a QStandardItem), which does setFlags()/setData() on it.
ElementDialog::execConfiguredDialog() deletes the dialog immediately
after exec() returns:
element_dialog->exec();
...
delete element_dialog;
That destroys the tree view and its ElementsCollectionModel, which as
a QStandardItemModel frees all its items in its destructor. Nothing
waited for the QtConcurrent::map() to finish first, so on Cancel before
loading completes, background threads were still calling setUpData()
on items the main thread had just freed - a use-after-free race.
Add an ElementsCollectionModel destructor that waits for the future
before QStandardItemModel's destructor runs. QFuture::waitForFinished()
on a default-constructed (never-started) future returns immediately, so
this is a no-op whenever loading already completed - the crash path is
the only one affected.
Fix print window clipping diagram when titleblock on right edge is hidden.
Fixes a frequently made mistake: confusing width and height when rotating something... 😉
Cross-references were missing from DXF exports, as reported on the
forum: https://qelectrotech.org/forum/viewtopic.php?id=2481
generateDxf() walks the scene and collects items by cast. A slave
element's cross-reference label ("(6-G15)", pointing back to its master)
is a plain QGraphicsTextItem hung off a DynamicElementTextItem as a
child, so it matches neither the IndependentTextItem nor the
DynamicElementTextItem branch and was dropped on the floor. Nothing was
wrong with the label itself; it was simply never collected.
Collect it through the existing DynamicElementTextItem::slaveXrefItem()
accessor and draw it with the same placement, rotation and multi-line
handling as the other text items, using defaultTextColor() since a bare
QGraphicsTextItem has no DiagramTextItem::color().
Measured on examples/industrial.qet, comparing against the PDF export
(which renders the whole scene and so shows everything):
before after PDF
slave xrefs "(n-Xn)" 0 41 41
folio/position strings 317 358 403
The slave cross-references now match the PDF exactly.
Still missing, and not addressed here: the master-side cross-reference
table drawn by CrossRefItem, which accounts for the remaining 45
strings. CrossRefItem is a QGraphicsObject that renders itself with
custom QPainter code in three different modes (drawAsCross,
drawAsContacts, drawAsPlcTable) including contact symbols and rules, so
giving it a DXF representation is a larger piece of work than this.
"exclude_from_bom" is listed in QETInformation::elementInfoKeys() so the
project database can build the element_info table column for it, but it
is not a free-text property: ElementInfoWidget already gives it its own
"Exclure de la nomenclature" check box.
Because buildInterface() creates one ElementInfoPartWidget per key in
that list, the key also got a second, generic edit row. And since
translatedInfoKey() has no case for it and falls through to
"return QString()", that row carries no label at all - an anonymous edit
line at the bottom of the panel. currentInfo() then writes
exclude_from_bom unconditionally, so as soon as the user edits anything
the nameless row fills with "true"/"false".
Drop the key from the list buildInterface() iterates. The check box
remains the only way to set it, currentInfo() still writes it exactly as
before, elementInfoKeys() is untouched so the database schema and
elementquerywidget are unaffected, and predefinedKeys() already excluded
it from the custom-property rows.
Reported by plc-user on #642.
QVector<int>(Qt::DisplayRole) creates a vector of size 0 (since Qt::DisplayRole == 0), not a vector containing DisplayRole. Fixed
to {Qt::DisplayRole}.
The sam applies to QVector<int>(role) which gets changed to {role}.
<private/qpdf_p.h> (QPdfEngine::drawHyperlink) needs Qt's private GUI
module, previously flagged only by a #warning at compile time.
Qt >= 6.7 ships GuiPrivate as a proper find_package component, but some
distro packages (e.g. Ubuntu's qt6-base-private-dev, Qt 6.8.3) do not
install Qt6GuiPrivateConfig.cmake and only provide the implicit
Qt6::GuiPrivate target created alongside Qt6::Gui. Requesting the
component unconditionally would therefore break distro-Qt builds.
Instead: try the component quietly, then hard-verify the Qt6::GuiPrivate
target exists after the main find_package, failing at configure time
with an actionable message if the private headers are missing. The
compile-time #warning in pdf_links.cpp and projectprintwindow.cpp is
now redundant and removed.
Verified: cmake configure + compile of both translation units on
Ubuntu 25.04 / Qt 6.8.3 (system KF6), cmake configure on Qt 5.15.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
a) using a system provided KF6
b) downloading and compiling KF6
c) using the vendored-in re-creation of the functionality
The behaviour for both Qt5 and Qt6 is steered with the same two variables which were renamed to become version agnostic:
a) BUILD_WITH_KF=ON BUILD_KF=OFF
b) BUILD_WITH_KF=ON BUILD_KF=ON
c) BUILD_WITH_KF=OFF
The version is automatically derived from the chosen Qt major version.
Selecting more than one dynamic text field in the element editor silently
replaced every selected field's colour with the colour of the first one.
Nothing was clicked -- merely extending the selection destroyed the others'
colours, and the change went onto the undo stack as if the user had asked
for it.
Cause: updateForm() loads the current part's colour into the colour button
with m_color_kpb->setColor(). KColorButton::changed is emitted for a
programmatic setColor() just as it is for user interaction, and it is
connected to m_color_kpb_changed(), which applies the new colour to *every*
part in m_parts. So simply displaying the first part's colour wrote that
colour to all the others.
Every other widget in updateForm() is immune because it is wired to a
user-only signal -- on_m_x_sb_editingFinished(), on_m_frame_cb_clicked() --
which setValue() and setChecked() do not emit. The colour button is the one
control whose signal cannot distinguish the two, so block it while loading.
This also explains why the reporter saw it only when rubber-band selecting
bottom-to-top: the write happens only when the first part's colour differs
from what the button already shows, which depends on selection order.
Verified in the element editor with two dynamic texts, one red and one blue:
select the red one, then ctrl-click the blue one. Before: the blue text
turned red. After: both keep their colours. Changing the colour deliberately
with the button still applies to all selected texts, as intended.
Forum report (qelectrotech.org/forum, topic 3005, reporter oc67): a
project named e.g. "Mon_projet.avec_un_point.qet" exported to PDF as
"Mon_projet.pdf" - everything after the first "." in the filename was
silently dropped.
Root cause: ProjectPrintWindow::docName() used QFileInfo::baseName(),
which returns the filename up to the FIRST "." rather than stripping
only the final suffix. docName() feeds both the PDF print job's
setOutputFileName() and the QFileDialog::getSaveFileName default in
exportToPDF(), so the truncation showed up as the actual exported
file's name, not just a dialog suggestion.
sources/exportdialog.cpp's SVG/PNG/DXF export path already uses the
correct QFileInfo::completeBaseName() (strips only the last suffix) -
this fix brings the PDF/print path in line with that existing,
correct pattern rather than introducing a new approach.
Verified the exact before/after behavior with a standalone QFileInfo
test: baseName() on "Mon_projet.avec_un_point.qet" returns
"Mon_projet" (the bug); completeBaseName() returns
"Mon_projet.avec_un_point" (correct). Also did a clean incremental
build with no new warnings/errors.
Fix bugtracker #281: new-part wizard's element editor opens behind main window
Cannot reproduce on Debian/GNU Linux, but implementation is reasonable and clean!
Fix bugtracker #251: title block template with slash in name fails silently
There are some characters that are not allowed in filenames.
Absolutely correct to mark a filename containing (one of) them as invalid!
Saving a new user title block template (right-click "Cartouches
utilisateur" > "Nouveau modèle" > "Enregistrer sous") with a name
containing a slash (or other filesystem-reserved character) silently
did nothing, with no error shown. The entered name is turned directly
into a filename (TitleBlockTemplatesFilesCollection::toFileName()), so
e.g. "foo/bar" becomes a path "foo/bar.titleblock" -- since "foo/"
essentially never exists as a directory, the underlying file write
fails, but that failure was never surfaced:
- TitleBlockTemplateLocation::isValid() only checked for an empty
name, so an invalid name still counted as "valid" and got passed
through to save.
- QETTitleBlockTemplateEditor::saveAs(const TitleBlockTemplateLocation&)
discarded the bool result of setTemplateXmlDescription() and
unconditionally returned true, marking the undo stack clean as if
the save had actually succeeded.
Fix:
- isValid() now also rejects names containing \ / : * ? " < > |,
matching the character set that's actually unsafe once the name
becomes a filename.
- saveAs() (the no-arg entry point that asks the user for a location)
now shows a clear error dialog when the entered name is rejected,
distinguishing "user cancelled" (location.name() empty) from
"name was invalid" (non-empty but rejected by isValid()).
- saveAs(location) now checks setTemplateXmlDescription()'s return
value and shows an error dialog instead of reporting false success
on any future/other write failure, not just this one.
Verified: clean rebuild, only the intended files recompiled and
linked successfully. Live-tested under Xvfb: creating a new template
and using "Enregistrer sous" with the name "foo/bar" now shows
"Le nom « foo/bar » n'est pas valide : il ne doit pas contenir les
caractères suivants : \ / : * ? " < > |" instead of silently doing
nothing; reopening the save-as dialog afterward showed the name field
correctly empty (nothing was partially written). Saving again with a
valid name ("mytemplate_valid") completed with no error dialog, and
the resulting mytemplate_valid.titleblock file was confirmed present
on disk in the user's title-block collection directory.
ProjectView::askUserForFilePath() only appended the .qet extension when
FLATPAK_ID/SNAP_NAME were NOT set, on the assumption that the
xdg-desktop-portal file dialog used by sandboxed Snap/Flatpak builds
always appends the selected filter's extension itself (avoiding a
double ".qet.qet"). In practice, on the reporter's Snap/Ubuntu 22.04
setup the portal dialog does not append it, so the environment-based
skip left Save As producing a file with no extension at all.
Portal behavior isn't something QET controls or can reliably detect via
environment variables -- it depends on the desktop's actual portal
implementation/version. Rather than guessing per-environment, normalize
unconditionally: strip any existing .qet suffix (case-insensitive) and
re-append exactly one. This produces the correct single extension
whether or not the dialog already added it, on every environment.
Verified: clean rebuild, only the intended object file recompiled and
linked successfully. Wrote a standalone test of the normalization logic
covering no-extension, already-has-extension, uppercase-extension, and
a literal dot in the base filename -- all four produced exactly one
correct ".qet" suffix with no double-extension and no missing extension.
Not verified: the actual Snap-sandboxed portal dialog behavior itself,
since building/running the Snap package and testing its file-save
dialog under a portal is outside what's practical to set up in this
sandbox. Confidence rests on the fix removing the environment-guessing
entirely in favor of unconditional, dialog-implementation-agnostic
normalization, which is correct regardless of what the underlying
dialog does.
Double-clicking a placed element (or right-click > "Éditer l'élément")
opens its properties via Element::editProperty(), which constructs a
PropertiesEditorDialog with a real parent (QApplication::activeWindow()).
On macOS, a QDialog that has both a parent and Qt::WindowModal set falls
back to Cocoa's automatic sheet presentation. Reports (and this
codebase's own existing workarounds) indicate this can render stuck
centered on screen, non-draggable, with symmetric resize -- rather than
a proper attached, movable window -- unlike Linux/X11 where the same
dialog behaves as a normal draggable QDialog.
Two other dialogs in this codebase already explicitly opt into the
correct macOS sheet presentation for this exact reason:
ElementDialog::setUpWidget() and DiagramPropertiesDialog's setup both do
setWindowModality(Qt::WindowModal);
#ifdef Q_OS_MACOS
setWindowFlags(Qt::Sheet);
#endif
PropertiesEditorDialog -- used for editing Element, QetShapeItem, and
DiagramImageItem properties, all reached via double-click on a diagram
item -- had neither this opt-in nor an opt-out, so it likely fell into
the same automatic-sheet behavior but without the explicit flag,
matching the reported "stuck centered, can't drag" symptom.
Fix: apply the same setWindowModality()/Q_OS_MACOS Qt::Sheet pattern
already used by the other two dialogs, in PropertiesEditorDialog's
constructor -- fixing all three call sites (element, shape, and image
property editing) at once, since they share this one dialog class.
Verified: clean rebuild, all three call sites (element.cpp,
qetshapeitem.cpp, diagramimageitem.cpp) recompiled and linked
successfully with no errors or warnings.
Not verified: the actual reported symptom is macOS/Cocoa-specific
window presentation behavior, which cannot be reproduced or confirmed
fixed in this Linux/Xvfb sandbox -- no macOS environment is available
here. Confidence rests on the exact same fix pattern already being
established and presumably working for two other dialogs in this
codebase for the identical class of problem.
NewElementWizard::createNewElement() creates and show()s a QETElementEditor
for the freshly-created part, but never calls raise()/activateWindow().
On the reporter's macOS setup, the wizard (a modal sheet/child of the main
window) closing right before the new editor is shown apparently leaves the
main window as the active/key window, so the new editor window is created
but stays behind it -- and, being neither key nor frontmost, it also never
surfaces in the Dock's window list or the app's own Windows menu. This
matched the report exactly: the reporter saw the wizard finish with
seemingly no result, when in fact a new part genuinely was created and its
editor genuinely was opened, just hidden from view.
Fix: explicitly raise() and activateWindow() the new editor after show(),
so it becomes the frontmost/key window regardless of what state the wizard
leaves the main window in.
Verified: clean rebuild, only the intended object file recompiled and
linked successfully. Ran the full wizard flow live under Xvfb on Linux
(right-click user collection > "Nouvel élément" > through all 3 steps >
Finish) and confirmed the element editor opens correctly with a blank new
part, with no regression in the flow.
Not verified: the actual reported symptom is macOS-specific window-manager
behavior (key/frontmost window handling, Dock window-list registration),
which cannot be reproduced or confirmed fixed in this Linux/Xvfb sandbox --
no macOS or Wine-with-Cocoa environment is available here. raise()/
activateWindow() are the standard cross-platform Qt calls for this exact
problem and match the pattern already used elsewhere in the codebase
(QETApp::openElementLocations()'s already-open-editor branch), so
confidence rests on that precedent rather than a macOS-side confirmation.
XRefProperties::fromSettings() read the "xrefpos" QSettings key with no
default value. On a fresh install/project, the key doesn't exist yet, so
settings.value(...).toString() returns an empty string. QMetaEnum::keyToValue("")
returns -1 (invalid), which was then cast directly into m_xref_pos as
Qt::AlignmentFlag(-1) -- garbage, despite the class's own default
constructor documenting the intended default as Qt::AlignBottom.
This explains the reported symptom: dynamically generated cross-reference
text for master/slave-linked elements (e.g. magneto-thermal breaker,
thermal relay NC) rendered at an undefined position and overlapped the
element's own label, making the reference unreadable. The reporter's
manual workaround -- explicitly setting alignment to "Bottom" in Project
Properties > New Folio/Cross Referencing -- side-steps the bug precisely
by writing a valid "AlignBottom" value into QSettings, which fromSettings()
then reads back correctly on subsequent loads.
Fix: supply "AlignBottom" as the fallback default for the QSettings read,
matching the constructor's documented default and the reporter's
functioning workaround.
Verified: clean rebuild, only the intended object file recompiled and
linked successfully. Confirmed via a small standalone QMetaEnum test that
keyToValue("") returns -1/invalid while keyToValue("AlignBottom") returns
64 (== Qt::AlignBottom), reproducing the exact mechanism before the fix and
confirming the corrected default resolves to the intended value.
Not verified: a live before/after visual comparison of the rendered
cross-reference text position on an actual magneto-thermal/thermal-relay
diagram (would require constructing a multi-folio project with linked
master/slave elements and comparing label geometry, which was out of
scope for the time available). Confidence rests on the QMetaEnum
mechanism being unambiguous and the fix being a one-line default-value
correction with no other code path affected.
Fix crash changing dynamic text color and confirming with Enter (bugtracker #323)
Works like charm:
- color is updated immediately
- no additional errors or warnings
- no crash anymore!
Laurent Trinques