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
=================
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
