Comment on ticket 12641 regarding handling of some short cuts on macos with qt6.

[pdv]

This contains a report on an issue discussed in 
https://www.lyx.org/trac/ticket/12641. I have also looked at it and this 
is my conclusion. At this time the only feasible partial remedy I see 
would be to switch IM on/off depending on the language input selected by 
the user. This would solve the problem for roman languages and limit it 
to asian languages. Of course it would be better if qt6's switch of 
behaviour was reversed.
If there are no objections I would like to send the following to a 
relevant qt-forum.

pdv

====================

Since qt commit https://github.com/qt/qtbase/commit/9e1875483ceaf90 the 
handling of some short cuts by LyX (https://www.lyx.org/) on macos 
doesn't work anymore.

In that commit the default handling of key events was reversed. Before 
this commit key events were send for all key presses unless they were 
handled by the "input method" (IM) system primarely used by complex 
(asian) languages. After this commit. IM became the default system and 
key events are only send in 2 cases: simple text and commands involving 
a single modifier key. In a later commit a cancel operation was added as 
a third exception. The only way to revert to the former behaviour is to 
switch IM off by setting WA_InputMethodEnabled=false.

Before this change of behaviour LyX could deal with both systems with 
the IM switched on by default. After the switch the issuing of commands 
involving 2 modifier keys (e.g. ^CmdE to switch emphasis) did no longer 
work.

A very similar problem was reported in QTBUG-106516 and contains this 
comment, by Tor Arne Vestbø:

"... Input methods should only be enabled for controls that are doing 
"text input", where you want the text input system of the OS to play a 
part (for example in composing characters for languages like Korean or 
Japanese). In your case you are not doing text input, you are processing 
"raw" key events, so disabling IM makes sense, including on Windows and 
Linux."

Since the user might input asian language text, switching the IM off is 
not a solution. LyX could switch IM on or off depending on the keyboad 
input chosen by the user (asian or roman). This would solve the problem 
for roman languages but not for asian languages. After all I suppose 
that al least some 2-modifier commands also make sense for an asian 
language.

The question arises why the behaviour of qt has been reversed. This was 
to remedy QTDEBUG-46300. AquaSKK is an IM to input Japanese and it uses 
^I to switch the language on/off. In other words when inputting japanese 
characters AquaSKK still expects that ^I is handled regularly, and 
therefore the behaviour was reversed. (of course AquaSKK could easily 
have filtered out this one command). But the change was justified as 
follows:

"... The reason for this is that Qt's IM protocol was designed to handle 
composited text, so sending non-composited (but IM-initiated) text input 
as IM events is unexpected"

Fair enough, but I suppose that commands involving 2 modifier keys (or 
even more) also fall in this category and should also be handled as 
oridinary key events and not by the IM. But this may just be the 
beginning of an endless list of exceptions.
Was this reversion really the best possible solution for handling the 
initial bug?

Sources and references:

qt commits

    https://github.com/qt/qtbase/commit/9e1875483ceaf90
 
https://github.com/qt/qtbase/commit/60caec953f76b1c63ff526c84cc968b5f83eabdf
 
https://github.com/qt/qtbase/commit/57e99441102f96dd0180a6ead84d8e8b3bd6b6f0

qt bug reports

    https://bugreports.qt.io/browse/QTBUG-46300
    https://bugreports.qt.io/browse/QTBUG-71394
    https://bugreports.qt.io/browse/QTBUG-106516

=================