Le 29/09/2015 02:23, Guillaume Munch a écrit :
The bug <http://www.lyx.org/trac/ticket/9362> causes the keyboard to
malfunction and consistently causes deadlocks with data loss.
I've finally narrowed down the issue to the fact that LyX is currently
incompatible with IBus and in particular its asynchronous mode. The
setting is stable & master, and X11 + IBus.
There are two faulty behaviours:
1. Erroneous keyboard input and deadlock, after LyX has been overwhelmed
by key events.
2. Move commands continue way after the arrow key has been released.
Normally, excess move commands are ignored and the message:
"GuiWorkArea.cpp (1053): system is busy: scroll key event ignored"
is shown with "lyx -dbg key". With this bug, the message does not appear.
I observe the following:
* With asynchronous IBus, we have both issues 1 & 2. IBus is
asynchronous by default in Ubuntu.
* With synchronous IBus, we only have the issue 2. IBus can be set
synchronous with the command:
IBUS_ENABLE_SYNC_MODE=1 ibus-daemon --xim --replace
* Without ibus, there is no issue. IBus can be disabled just for LyX
with the command:
XMODIFIERS= src/lyx
According to a quick internet search, asynchronous IBus functionality is
necessary for the Hangul input method to function properly.
So there are really two bugs:
a. LyX should be fixed to support IBus.
b. Key event compression should be implemented properly. If it is really
done properly, then the responsiveness of LyX could be improved greatly;
it would mean e.g. treating repeated rightarrow keypresses as a single
LyX event "forward-char n" without updates in between, and chuncks of
texts would be input at once.
Is there any technical difficulty for implementing b.?
Here are a few links I gathered:
About a similar issue with Android Studio and its workaround at user level:
<https://stackoverflow.com/questions/30756488/keyboard-issues-with-android-studio-on-ubuntu>
About a similar issue in Chromium and its workaround at application level:
<https://src.chromium.org/viewvc/chrome/trunk/src/ui/base/ime/input_method_linux_x11.cc?r1=237027&r2=237026&pathrev=237027>
About a longer-term solution in Chromium:
<https://codereview.chromium.org/224723008>
About the inappropriateness of checking hasPendingEvents() to perform
event compression (cf. GuiWorkArea::keyPressEvent())
<https://stackoverflow.com/a/21488676>
<https://bugreports.qt.io/browse/QTBUG-36611?focusedCommentId=230881&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-230881>
About setting Qt::WA_KeyCompression to enable key event compression
(unfortunately only for printable characters):
<http://doc.qt.io/qt-4.8/qt.html#WidgetAttribute-enum>
About various solutions for implementing compression for other kinds of
events:
<https://stackoverflow.com/a/20939793>
Decision has to be taken about the keyboard issues and deadlock in
<http://www.lyx.org/trac/ticket/9362> under Linux with IBus.
The issue is going to be solved by Qt5, but unfortunately due to
<http://www.lyx.org/trac/ticket/9731> (related to event compression as
well!) the recommended version for Qt on Linux is 5.6 which is still in
development.
So we are more looking for a temporary workaround than a proper fix.
1. One possibility is to set IBus to synchronous mode from LyX:
<http://www.lyx.org/trac/ticket/9362#comment:32>. But then we must find
a way to do so without breaking the hangul input method for our Korean
friends.
2. Another speculative solution
(<http://www.lyx.org/trac/ticket/9362#comment:43>) is to implement a
prototype key event compression (cf.
<http://www.lyx.org/trac/ticket/9790>), even if we don't benefit from
performance improvements immediately (I believe that the hard work for
this has more to do with the performance improvement part).
Solution 2. promises more fun, but 1. is quicker provided that we find a
solution to keep hangul functional.
Maybe you have a solution 3.
Guillaume
