From 762bd7febf4ad65e94f1e8dcadf7ea3deea1684b Mon Sep 17 00:00:00 2001 From: ispyisail Date: Wed, 12 Aug 2026 15:53:30 +1200 Subject: [PATCH] Fix bugtracker #333: selecting several dynamic texts overwrites their colours 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. --- sources/editor/ui/dynamictextfieldeditor.cpp | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/sources/editor/ui/dynamictextfieldeditor.cpp b/sources/editor/ui/dynamictextfieldeditor.cpp index 145dd959a..5b48d30fd 100644 --- a/sources/editor/ui/dynamictextfieldeditor.cpp +++ b/sources/editor/ui/dynamictextfieldeditor.cpp @@ -31,6 +31,7 @@ #include #include #include +#include DynamicTextFieldEditor::DynamicTextFieldEditor(QETElementEditor *editor, PartDynamicTextField *text_field, @@ -143,7 +144,18 @@ void DynamicTextFieldEditor::updateForm() ui->m_rotation_point_center_cb->setChecked(m_text_field.data()->rotationPointCenter()); #ifdef BUILD_WITHOUT_KF5 #else - m_color_kpb -> setColor(m_text_field.data() -> color()); + //Block signals while loading the colour into the button. + //KColorButton::changed fires on a programmatic setColor() as well + //as on user interaction, and m_color_kpb_changed() applies the new + //colour to *every* selected part -- so merely showing the first + //part's colour would overwrite the colour of all the others. + //The other widgets above are immune because they are wired to + //user-only signals (editingFinished, clicked), which setValue() + //and setChecked() do not emit. + { + const QSignalBlocker blocker(m_color_kpb); + m_color_kpb -> setColor(m_text_field.data() -> color()); + } #endif ui -> m_width_sb -> setValue(m_text_field.data() -> textWidth()); ui -> m_font_pb -> setText(m_text_field -> font().family());