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

Stephan Witt st.witt at gmx.net
Thu Mar 28 09:53:08 UTC 2024


Am 28.03.2024 um 10:44 schrieb pdv <pdvisschere at edpnet.be>:
> 
> 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

Hi Patrick,

I’d be more than happy if you’ll do this.

Thank you.

Stephan

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



More information about the lyx-devel mailing list