Re: Comment on ticket 12641 regarding handling of some short cuts on macos with qt6.
On Mon, Apr 08, 2024 at 10:41:43AM GMT, Jean-Marc Lasgouttes wrote: > Le 08/04/2024 à 10:20, pdv a écrit : > > Tor Arne Vestbø posted a qt-patch solving this issue. > > See: https://bugreports.qt.io/browse/QTBUG-123848 > > Great job Patrick! Now we just have to wait for it to be available. +1 thanks for taking the time to do that, Patrick! If this is serious enough we might want to mention this in the recommendations of Qt versions for macOS users in the release notes. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Comment on ticket 12641 regarding handling of some short cuts on macos with qt6.
Le 08/04/2024 à 10:20, pdv a écrit : Tor Arne Vestbø posted a qt-patch solving this issue. See: https://bugreports.qt.io/browse/QTBUG-123848 Great job Patrick! Now we just have to wait for it to be available. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Comment on ticket 12641 regarding handling of some short cuts on macos with qt6.
On 29/03/2024 22:40, pdv wrote: On 29/03/2024 11:31, Jean-Marc Lasgouttes wrote: Le 28/03/2024 à 23:04, pdv a écrit : I submitted the following bug report https://bugreports.qt.io/browse/QTBUG-123848 pdv Hi Patrick, Thanks for doing that! Frankly I don't use shortcuts very often and I never use asian languages, but I cannot resist a challenge. Therefore I gave it a try and came to the conclusion that there is no easy way out. An alternative idea I had was be to install a global event filter at GuiApplication level that would detect and handle shortcut. Does this seem possible to you? And if yes, does this seem like a good idea or a kludge? I have indeed only looked to the key handling at the Widget level. Is there a possibility to receive all key events at the application level? If yes then maybe your proposal might work. But shouldn't key handling be done preferentially by the widget involved? With the qt5 behavior lyx could handle all situations correctly and AquaSKK should have done something similar. We'll see what the qt-developers think about it. They may have had other reasons for switching the behavior. pdv JMarc Tor Arne Vestbø posted a qt-patch solving this issue. See: https://bugreports.qt.io/browse/QTBUG-123848 pdv -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Comment on ticket 12641 regarding handling of some short cuts on macos with qt6.
On 29/03/2024 11:31, Jean-Marc Lasgouttes wrote: Le 28/03/2024 à 23:04, pdv a écrit : I submitted the following bug report https://bugreports.qt.io/browse/QTBUG-123848 pdv Hi Patrick, Thanks for doing that! Frankly I don't use shortcuts very often and I never use asian languages, but I cannot resist a challenge. Therefore I gave it a try and came to the conclusion that there is no easy way out. An alternative idea I had was be to install a global event filter at GuiApplication level that would detect and handle shortcut. Does this seem possible to you? And if yes, does this seem like a good idea or a kludge? I have indeed only looked to the key handling at the Widget level. Is there a possibility to receive all key events at the application level? If yes then maybe your proposal might work. But shouldn't key handling be done preferentially by the widget involved? With the qt5 behavior lyx could handle all situations correctly and AquaSKK should have done something similar. We'll see what the qt-developers think about it. They may have had other reasons for switching the behavior. pdv JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Comment on ticket 12641 regarding handling of some short cuts on macos with qt6.
Le 28/03/2024 à 23:04, pdv a écrit : I submitted the following bug report https://bugreports.qt.io/browse/QTBUG-123848 pdv Hi Patrick, Thanks for doing that! An alternative idea I had was be to install a global event filter at GuiApplication level that would detect and handle shortcut. Does this seem possible to you? And if yes, does this seem like a good idea or a kludge? JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Comment on ticket 12641 regarding handling of some short cuts on macos with qt6.
I submitted the following bug report https://bugreports.qt.io/browse/QTBUG-123848 pdv -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Comment on ticket 12641 regarding handling of some short cuts on macos with qt6.
Am 28.03.2024 um 10:44 schrieb 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 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
Comment on ticket 12641 regarding handling of some short cuts on macos with qt6.
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
