Merge pull request #726 from ispyisail/fix/bugtracker-333-multiselect-text-color

Fix bugtracker #333: selecting several dynamic texts overwrites their colours
Merge pull request #725 from ispyisail/fix/pdf-export-filename-multiple-dots-forum3005
2026-09-27 12:34:14 +02:00 · 2026-08-13 09:39:36 +02:00 · 2026-08-13 09:22:48 +02:00 · 2026-08-12 15:53:30 +12:00 · 2026-08-12 10:31:04 +12:00
2 changed files with 14 additions and 2 deletions
@@ -31,6 +31,7 @@
 #include <QColorDialog>
 #include <QGraphicsItem>
 #include <QPointer>
+#include <QSignalBlocker>

 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());
@@ -108,7 +108,7 @@ QString ProjectPrintWindow::docName(QETProject *project)
 {
 	QString doc_name;
 	if (!project->filePath().isEmpty()) {
-		doc_name = QFileInfo(project->filePath()).baseName();
+		doc_name = QFileInfo(project->filePath()).completeBaseName();
 	} else if (!project->title().isEmpty()) {
 		doc_name = project->title();
 		doc_name = QET::stringToFileName(doc_name);
Author	SHA1	Message	Date
plc-user	b7efbdc323	Merge pull request #726 from ispyisail/fix/bugtracker-333-multiselect-text-color Fix bugtracker #333: selecting several dynamic texts overwrites their colours	2026-08-13 09:39:36 +02:00
plc-user	b00e053dab	Merge pull request #725 from ispyisail/fix/pdf-export-filename-multiple-dots-forum3005 Fix PDF export truncating project filenames at the first dot	2026-08-13 09:22:48 +02:00
ispyisail	762bd7febf	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.	2026-08-12 15:53:30 +12:00
ispyisail	162d43e1c9	Fix PDF export truncating project filenames at the first dot 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.	2026-08-12 10:31:04 +12:00