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

List:       pykde
Subject:    Re: PyQt6 QWidget.keyPressEvent() behaviour changed?
From:       Marko Luther <marko.luther () gmx ! net>
Date:       2021-12-02 12:11:54
Message-ID: D28AE0AD-C37E-43D2-B533-85B7F597E07A () gmx ! net
[Download RAW message or body]

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

> On 17. Nov 2021, at 21:44, Baz Walter <bazwal@gmail.com> 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.


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