PyQt6 QWidget.keyPressEvent() behaviour changed?

Marko Luther marko.luther at
Thu Dec 2 12:11:54 GMT 2021

The issue just got fixed by Qt 6.2.2 / PyQt6.2.2

> On 17. Nov 2021, at 21:44, Baz Walter <bazwal at> wrote:
> On 17/11/2021 15:14, Marko Luther wrote:
>> Hm. How to handle this cross-platform. PyQt5 and PyQt6 show identical results on Windows 10.
>> # h
>> 72 h False True
>> # alt
>> 16777251 True False
>> # alt h
>> 72 h True True
>> but different to macOS.
> That's the expected result on Windows and Linux, because the Alt and AltGr modifiers have distinct functional roles. However, on MacOS, the Option key must somehow perform both roles. With native programs it must function like AltGr, but with non-native ones it must function like Alt.
> The issue is whether the Option modifier should behave like Alt with Qt-based programs, or like AltGr. It seems you expect the former - and I'm not going to dispute that (since I'm not a MacOS user). But even so, the Qt5 behaviour on your system still looks inconsistent to me, because you show the following output for Option/Alt+H:
>    # 72 ª True True
> whereas it "should" be:
>    # 72 h True True
> The Qt6 behaviour is at least self-consistent, even if it's not as expected:
>    # 170 ª True False
> But is it intentional that the text does not match the key in Qt5? It would be interesting to see what the behaviour was in Qt4. Perhaps the inconsistency is actually an intentional compromise that reflects the dual nature of the Option/Alt modifier on MacOS. If that's the case, the Qt6 behaviour could be seen as a regression, and should be reported on the Qt issue tracker.

More information about the PyQt mailing list