- start a portal'd kate
- then ctrl-q the kate (leave the dialog open)
result: dialog stays open even though the kate instances that started it is now gone
expected: dialog disappears when kate gets closed
possible solution: since a client requesting a portal method must have some dbus address, the portal can listen for the address getting unregistered on the bus at which point the portal should also discard all pending dialogs to do with the client
I am not able to reproduce this. I followed the exact steps outlined in your report.
Please confirm if this is still an issue and include version details.
Operating System: Manjaro Linux
KDE Plasma Version: 5.20.3
KDE Frameworks Version: 5.77.0
Qt Version: 5.15.1
Kernel Version: 5.9.10-1-MANJARO
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-6200U CPU @ 2.30GHz
Memory: 7.7 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 520
The GUI is now blocked it seems.
When you start it from a terminal and ctrl-c the lead process the dialog will still remain open though, i.e. the actual problem that the portal doesn't react to the client disappearing is still there.
Git commit b32240b9e898fbf2ec1201e3628c8357c4af6676 by Harald Sitter.
Committed on 22/04/2022 at 09:37.
Pushed by ngraham into branch 'master'.
add Request closing support to all rejectable dialogs
this ensures that the dialog goes away when the app disappears while the
dialog is still up (e.g. when ctrl-c'ing the app)
this simply refactors the existing Request code to correctly register on
the path and then emit the closerequest that gets routed to the ::reject
function of the dialog. for extra flexibility this is implemented as a
template such that the concrete type doesn't matter so long as it has a
M +3 -0 src/access.cpp
M +3 -0 src/appchooser.cpp
M +2 -0 src/dynamiclauncher.cpp
M +4 -0 src/filechooser.cpp
M +1 -11 src/inhibit.cpp
M +3 -0 src/print.cpp
M +3 -0 src/remotedesktop.cpp
M +14 -1 src/request.cpp
M +12 -1 src/request.h
M +3 -0 src/screencast.cpp
M +3 -0 src/screenshot.cpp