https://bugs.kde.org/show_bug.cgi?id=354724
--- Comment #27 from Andreas Hartmetz <ahartm...@gmail.com> --- You can't just send fake close events to clients that don't expect that. That... technique... is a KDE specialty. KDE applications are written to deal with it. In the general case, though, it is legitimate to start destroying internal data structures in a close event, and it is legitimate not to expect more than one close event before the window is actually closed. Case in point: fixing KMainWindow and KApplication to restore their KDE4 behavior (I have locally tested Qt and KDE patches to that effect) makes Kate crash on logout. Changing behavior but not API is *worse* than adding API that optionally changes behavior - it silently breaks expectations of existing software. We can, however, implement a workaround in KDE (and then fix our stuff when something breaks): At the end of the slot handling commitDataRequest(), install an event filter on the QGuiApplication, which nicely filters ALL events to everything (TODO: check that - otherwise we'd just install an event filter on all toplevel windows). In that filter, check whether QGuiApplication::isSavingSession() is still true: if so, filter out and ignore() all CloseEvents. If not, have the the filter uninstall and delete itself for performance reasons. If you look at QWidgetPrivate::close_helper(), you see that it always sends a close event to ask windows if they agree to be closed, and they can always refuse. Now which repository should that go in? It would be ugly to copy and paste the necessary code around - it should be roughly ten lines. -- You are receiving this mail because: You are watching all bug changes.
