graesslin added a comment.
To me the question is rather: can we ensure that other users of KKeyServer didn't get broken by the change. What KWin did could be considered a bug or an application misuse. KWin used the Qt key and compared it directly to Qt::Key_Enter. That one doesn't work anymore as it's no longer Qt::Key_Enter, but KeyEnter | NumpadModifier. So any usage of KKeyServer which just didn't care about whether it's numpad or not will be broken if it did a direct key comparison. Or if they had a special numpad handling it will be broken. Looking at lxr I fear that also kscreenlocker might be broken now. That's the problem we have with changing this legacy code as I mentioned in the other bug report - even if it's a bug fix or a sensible extension like in this case. The code around just breaks as it expects a special behavior and we are not able to find all the cases without it breaking just everywhere around us. I hope you understand better why I was so pessimistic about the change in the other review. It's just my experience that touching this code breaks stuff. REPOSITORY R278 KWindowSystem REVISION DETAIL https://phabricator.kde.org/D6233 To: dfaure, graesslin Cc: bcooksley, graesslin, #frameworks
