Short cuts involving 2 (or more) modifier keys are not longer handled by the Input Methods on macos.

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 primarily 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 behavior is to switch IM off by setting WA_InputMethodEnabled=false.

 Before this change of behavior 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 behavior 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 behavior 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?

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