Bug 491083 - Closing System Settings' main window while a KNS dialog is open leaves the process running with no UI
Summary: Closing System Settings' main window while a KNS dialog is open leaves the pr...
Status: RESOLVED FIXED
Alias: None
Product: frameworks-knewstuff
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR major
Target Milestone: ---
Assignee: Dan Leinir Turthra Jensen
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-07-31 19:58 UTC by Nate Graham
Modified: 2024-08-29 04:06 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.6
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nate Graham 2024-07-31 19:58:48 UTC
Current git master everything built against Qt 6.7.2 on top of Fedora KDE 40.


STEPS TO REPRODUCE
1. Launch System Settings from a terminal window
2. Navigate to any KCM with a "Get New" button on it
3. Click the "Get New" button
4. Close the System Settings main window


OBSERVED RESULT
systemsettings process is still running in the background.


EXPECTED RESULT
systemsettings process terminates immediately
Comment 1 Bug Janitor Service 2024-08-01 13:30:21 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/knewstuff/-/merge_requests/328
Comment 2 Harald Sitter 2024-08-27 12:34:44 UTC
Git commit 280edadfd9b2fd7e683924462b1565f8a1fbacc8 by Harald Sitter.
Committed on 27/08/2024 at 12:32.
Pushed by sitter into branch 'master'.

add especially crappy magic to deal with transient parents in actions

the issue is fairly involved and I am not sure I fully grasp it...

systemsettings has a fairly exotic line up of window entities that form
the final window. transient to that window it should create the KNS
windows. unfortunately that doesn't work right now because the
transience is not explicitly set.

this has in part to do with the also very exotic setup of
NewStuff.Action which internaly has a private QObject and inside that a
property of the type NewStuff.Dialog (the window in question).

now ordinarily there is actual magic code inside qquickwindow to figure
transience out automatically, except it fails here because the parent of
the Dialog is neither an Item nor a Window (it is a QObject of course),
so the magic has no way to deal with it without making a lot of
assumptions about the parent tree.

to fix this situation we introduce a magician assistant. it will first
and foremost warn that this situation is garbage and the developer ought
to provide an explicit transient.
it will then proceed to identify the first QQuickItem in the parent
chain with a window and adopt that window as transient parent. i.e. the
first window we find becomes parent.

the end result is that our Dialog always has a transient parent (when
used as part of Action)

M  +2    -0    src/qtquick/CMakeLists.txt
A  +15   -0    src/qtquick/private/CMakeLists.txt
A  +55   -0    src/qtquick/private/transientmagicianassistant.cpp     [License: LGPL(3+eV) LGPL(v3.0) LGPL(v2.1)]
A  +25   -0    src/qtquick/private/transientmagicianassistant.h     [License: LGPL(3+eV) LGPL(v3.0) LGPL(v2.1)]
M  +3    -0    src/qtquick/qml/Action.qml

https://invent.kde.org/frameworks/knewstuff/-/commit/280edadfd9b2fd7e683924462b1565f8a1fbacc8