PyQt6 QWidget.keyPressEvent() behaviour changed?

[Marko Luther]

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. Hm. So is this a Qt or PyQt bug on macOS only?

Does anybody else has more information on this and what the correct result should be?

Thanks,
Marko


> On 16. Nov 2021, at 19:01, Baz Walter <bazwal at gmail.com> wrote:
> 
> On 16/11/2021 16:14, Marko Luther wrote:
>> This is using the lastest PyQt5/6 from pip on macOS 11.6. I guess the PyQt5 result is correct as this delivers the modifier and the key-press separate. The key should  in the best case match the corresponding item in the enum Qt.Key. Thus the key() result is just an int and not an enum element.
> 
> No, the PyQt5 behaviour is clearly wrong on your system. There's a one-to-one mapping between most of the ascii codes and the Qt.Key enum. The character ª is the feminine ordinal indicator. That is ascii 0x0aa (170), which is the same as Qt.Key_ordfeminine. (If a key combination produces a character that isn't enumerated by Qt.Key, the unicode code-point will be returned instead). The Qt6 behaviour is correct. The QKeyEvent.key() method returns the *mapped* key (where applicable), not the *physical* key.
> 
>> I wonder how best to resolve this. In my case I have to catch the H-key press, independent of any modifier key that might have pressed at the same time.
> 
> What exactly do you mean by "H-key press"? There's never any guarantee that the keyboard attached to the system will have a physical key with an "H" printed on it. And even if does, there's no guarantee that it will be mapped to the ascii character "H". Literally any key combination could produce a event for which QKeyEvent.key() returns Qt.Key_H - it all depends on what the current keyboard mapping is.