[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pykde
Subject:    Re: PyQt6 QWidget.keyPressEvent() behaviour changed?
From:       Baz Walter <bazwal () gmail ! com>
Date:       2021-11-17 20:44:05
Message-ID: 72a604eb-d301-892d-c5c6-cc182275456c () gmail ! com
[Download RAW message or body]

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.


[prev in list] [next in list] [prev in thread] [next in thread]