From 6ad2a63575bcbae68f22c4b4ad6f125c64629ed6 Mon Sep 17 00:00:00 2001 From: ispyisail Date: Tue, 11 Aug 2026 11:33:28 +1200 Subject: [PATCH] Fix bugtracker #281: new-part wizard's element editor opens behind main window MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. --- sources/newelementwizard.cpp | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sources/newelementwizard.cpp b/sources/newelementwizard.cpp index afa30fa9e..3cd3870e8 100644 --- a/sources/newelementwizard.cpp +++ b/sources/newelementwizard.cpp @@ -252,4 +252,10 @@ void NewElementWizard::createNewElement() loc_.addToPath(m_chosen_file); edit_new_element -> setLocation(loc_); edit_new_element -> show(); + // Without this, the just-closed wizard can leave the main window + // as the active/key window (bugtracker #281, reported on macOS): + // the new editor is created and shown, but stays behind the main + // window and doesn't surface in the Dock/Windows menu. + edit_new_element -> raise(); + edit_new_element -> activateWindow(); }