422880c9db
When the Command key is pressed AppKit seems to do key equivalent matching using a Latin/Roman interpretation of the current keyboard layout. For example, for a Greek layout, pressing Option+Command+C produces a key event with chars="ç" and unmodchars="ψ", but AppKit still treats this as a match for a key equivalent of Option+Command+C. We can't do the same by just applying the modifiers to our key map, as that too contains "ψ" for the Option+Command combination. What we can do instead is take advantage of the fact that the Command modifier layer in all/most keyboard layouts contains a Latin layer. We then combine that with the modifiers of the event to produce the resulting "Latin" key combination. If the unmodified key is outside of Latin1, we also treat that as a valid key combination, even if AppKit natively does not. For example, for a Greek layout, we still want to support Option+Command+ψ as a key combination, as it's unlikely to clash with the Latin key combination we added above. However, if the unmodified key is within Latin1, we skip it, to avoid these types of conflicts. For example, in the same Greek layout, pressing the key next to Tab will produce a Latin ';' symbol, but we've already treated that as 'q', thanks to the Command modifier, so we skip the potential Command+; key combination. This is also in line with what AppKit natively does. Fixes: QTBUG-96371 Fixes: QTBUG-79493 Task-number: QTBUG-112736 Change-Id: I30d678c1c7860642d3eed29c7757133ff74c6521 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> |
||
---|---|---|
.. | ||
3rdparty | ||
android | ||
assets | ||
concurrent | ||
corelib | ||
dbus | ||
entrypoint | ||
gui | ||
network | ||
opengl | ||
openglwidgets | ||
platformsupport | ||
plugins | ||
printsupport | ||
sql | ||
testlib | ||
tools | ||
widgets | ||
xml | ||
CMakeLists.txt |