<table><tr><td style="">graesslin added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D6233" rel="noreferrer">View Revision</a></tr></table><br /><div><div><p>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.</p>

<p>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.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R278 KWindowSystem</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D6233" rel="noreferrer">https://phabricator.kde.org/D6233</a></div></div><br /><div><strong>To: </strong>dfaure, graesslin<br /><strong>Cc: </strong>bcooksley, graesslin, Frameworks<br /></div>