graesslin added a comment.
In https://phabricator.kde.org/D8705#166045, @dfaure wrote: > I guess that the same argument could be made about Qt5::Widgets... if you're using a widget you're supposed to link to that, rather than indirectly via KWindowSystem... > > This is making me change my mind. Maybe it's OK after all. It breaks SC in a case where "proper" application code shouldn't be affected. I'm not totally happy with this as @apol showed with the list of reviews he already put up that this causes compile breakage for many products. I don't mind getting rid of QWidget in KWindowSystem - in fact I would even prefer if we could get rid of it completely and was very sad when I realized we missed the 5.0 slot for it. But I think we shouldn't just break existing software. Especially given the short release cycles we have and the encouragement to distros to ship such versions. It would not be good for us if distros cannot rely on our own code to compile with latest frameworks. Thus I suggest we do this in two steps: introduce a build option which enforces the old behavior and keep this the default. In half a year change the default and with KF 6 remove it completely. This just gives the whole stack more time to catch up and we hopefully don't run into the situations that things break. Oh and kdesrc-build should be adjusted to enable the build option from the start, so that our own code falls on our feet. REPOSITORY R278 KWindowSystem REVISION DETAIL https://phabricator.kde.org/D8705 To: apol, #frameworks, dfaure Cc: graesslin, dfaure, anthonyfieroni
