https://bugs.kde.org/show_bug.cgi?id=354724
--- Comment #24 from Thomas Lübking <thomas.luebk...@gmail.com> --- (In reply to Alexey Chernov from comment #23) > Comments like this clearly don't help Seriously, you asked for breaking clients because that's what you'd "like" to do - what did you expect to hear? That's simply not an acceptable stance. > Never mentioned minor update or particular version. Please don't distort. So you meant to schedule this for Qt6? > Users were already hit when the significant part of functionality important > for someone's every day use case is broken. Let's be honest: session restorage is apparently relevant for only a minority of users. Loosing your data is however relevant for everyone. And the latter is the by far more severe issue. Restarting applications is merely an annoyance, loosing your work is truely expensive. Also there's absolutely NO reason why we should not care about both - except that you'd "like" to break client code and risk data loss for some reason that completely escapes me. > Still better than a couple of API methods like "enableSpecifiedBehaviour()" I fully agree on that proposal to be of little help - it will be mostly ignored or used w/o accounting the implications. > Once again: we all could already apply the fix of Andreas and be busy fixing > the necessary applications rather than keep discussing here. It does NOT only affect KDE applications, there're hundreds of Qt applications which might have adopted this pattern - or simply don't care about session management itfp. Also the proper order is to fix and roll out clients, *then* remove the deprecated upstream code. That's why "=> Qt6" for this approach. > On the Qt6 release you would say that everyone already rely on the > workaround there was in Qt5 etc. etc. No. Because you would tell people during Qt5 don't do this and don't rely on it because it's not gonna work with Qt6, so that when things are ported to Qt6, client code has to be fixed. Breaking it now and depending client behavior on whether it's linked against Qt 5.6 or Qt 5.7 is plain wrong and begging for trouble. > I just kindly remind your description of current Plasma 5 and it's > application state: https://bugs.kde.org/show_bug.cgi?id=341930#c30. Off topic? This was a global statement. Session management in particular is a different thing: few people seem to really care about restoring sessions. > In a couple of years We'll have seen Qt6 and this removed, but even if not - it doesn't matter. The QGuiApplication code will have a "// TODO Qt6" comment and the client code does not care about why there's a close event (which might be rejected, thus not causing eg. deletion anyway) > The only arguable point is whether it's safe to have it fixed now or should > another (possible API-changing) workaround should be added instead. No. Actually I propose to fix the "workaround" already present in QGuiApplication by turning "close()" into just sendind a close event (for that's actually the desired action) and by this fix session storage and maintain data protection with the present approaches. Breaking that behavior may happen for Qt6, anything else will be perceived as regression. On a sidenote: QGuiApplication::commitDataRequest() may be the "preferred" hook, but there's actually nothing that explicitly forbids "fake a close in addition", notably since it will trigger similar, if not equal client code. Given the status quo, I'd probably even just remove the commitDataRequest signal in Qt6 and rely only on faking close events - why should client code have to care about two different "aboutToClose" signals? Sounds stupid to me. -- You are receiving this mail because: You are watching all bug changes.
