https://bugs.kde.org/show_bug.cgi?id=354724
--- Comment #22 from Thomas Lübking <thomas.luebk...@gmail.com> --- > 5. I completely don't like the proposed way to preserve the compatibility > with (4) and make > the use case of broken session management client implementation legal and > default, but > also try to allow proper-written apps to still survive somehow, adding some > strange > workarounds to Qt as closing all the windows, but not too much, or API > properties to enable > proper processing of SM messages. No ofense, but what you "like" is completely irrelevant. You propose to intentionally break clients by library changes in some minor update, to teach developers to do right, but while you might aim their face, you're gonna hit the users (and probably yours) We had that (I kindly remind of the qDeleteAll fix ...) and it cooked up hell. commitDataRequest hardly shows up in lxr.kde.org, what means it's probably not used at all and aboutToQuit (which isn't used but could come to rescue) isn't used too much either. The BY FAR! omnipresent pattern is to listen to queryClose() which is called/emitted on -guess what- close events from KMainWindow. And that's for pretty much sure why the (wrong) behavior in QSessionManager exists. Is this behavior correct? No. Does this matter? NO! It's ok to spam a #warning that this behavior is shit and deprecate and kill it for Qt6 and we might even bail out (aka "fix") KMainWindow applications NOW by invoking queryClose() on QGuiApplicationPrivate::commitData() but regardless, we MUST assume this to be a global default pattern that applications (also beyond KDE) rely on (also because it's absolutely natural to intercept closing to save data and not think of closing on session end could be something entirely different - actually the illegal behavior happens to be the most sane one...) Now, *actually* closing windows to test interaction on session end is of course just as wrong - if the user cancels the logout by such incident, we should not have closed random other windows before (letting alone that it causes this but) - therefore I frankly do not understand what's so complicated about just faking a close event to serve the present "save your stuff" pattern in a majority in clients without causing the destructive close itself which may not only be a bit premature, but also triggers this bug. It's the least invasive solution that does not require everyone to signal "yes, i can sessionmanagement" (what's not gonna happen) and we don't risk loosing the users data (or breaking the ability to cancel the logout) -- You are receiving this mail because: You are watching all bug changes.
