From 325b895d0b78c68a3eb4cc1c88de9b8832f0b6c6 Mon Sep 17 00:00:00 2001 From: ispyisail Date: Tue, 11 Aug 2026 11:48:58 +1200 Subject: [PATCH] Fix bugtracker #275: element properties window stuck centered on macOS MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. --- sources/PropertiesEditor/propertieseditordialog.h | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/sources/PropertiesEditor/propertieseditordialog.h b/sources/PropertiesEditor/propertieseditordialog.h index b76b5c422..50cb96aef 100644 --- a/sources/PropertiesEditor/propertieseditordialog.h +++ b/sources/PropertiesEditor/propertieseditordialog.h @@ -46,6 +46,18 @@ class PropertiesEditorDialog : public QDialog PropertiesEditorDialog(T editor, QWidget *parent = nullptr) : QDialog (parent) { + // Without this, a QWidget-modal QDialog with a parent falls + // back to macOS's automatic sheet presentation, which some + // Qt/Cocoa versions render stuck centered on screen and + // non-draggable rather than as a proper attached sheet + // (bugtracker #275). Other dialogs in this codebase already + // opt in explicitly (see ElementDialog, DiagramPropertiesDialog) + // -- this one was missing it. + setWindowModality(Qt::WindowModal); +#ifdef Q_OS_MACOS + setWindowFlags(Qt::Sheet); +#endif + //Set dialog title setWindowTitle(editor->title()); // Reparent the editor,