Am 28.03.2024 um 10:44 schrieb pdv <pdvissch...@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@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
