diff options
author | Michael Weghorn <m.weghorn@posteo.de> | 2020-02-28 09:05:17 +0100 |
---|---|---|
committer | Michael Weghorn <m.weghorn@posteo.de> | 2020-02-28 10:49:31 +0100 |
commit | 1c6ea413cb01c0b482f87e625ba208eec230618a (patch) | |
tree | 3c4aeec71508ede393b36b674759b3bd7df5aec4 /icon-themes/elementary/cmd | |
parent | 24caeee8236576abd92086974c1dbbf15b81a4c5 (diff) |
tdf#130071 tdf#127815 qt5: Use ExtTextInput only for multi-char key events
Only call the SalEvent::ExtTextInput callback for key input events
if their text is longer than one character, in which case treating them
as SalEvent::KeyInput would produce incorrect results, given that only
the first character is set as the SalKeyEvent's mnCharCode below
(s.a. tdf#124118).
S.a. commit 61c8324394c690ced18ce692ab6d29c8031ad1a8
("#88063# fixed event handling for redflag", 2001-06-12)
which made events with text longer than 1 unicode char
to be handled by SalEvent::ExtTextInput for the gen VCL plugin even
if not in preedit mode.
Process other key events by calling SalEvent::KeyInput callback, which
e.g. makes shortcuts involving non-Latin characters (tdf#130071) and
auto-insertion of non-breaking spaces when typing French text
(tdf#127815) work.
The gtk3 and gen VCL plugins also use the length of the text as one
criterion to make a disctinction of whether to call SalEvent::ExtTextInput
or SalEvent::KeyInput, s. GtkSalFrame::IMHandler::signalIMCommit and
X11SalFrame::HandleKeyEvent. Those also take into account whether
in preedit mode, but for the qt5 case, input method events when using
e.g. ibus are handled in Qt5Widget::inputMethodEvent and the
Qt5Widget::handleKeyEvent code path is not used anyway.
Change-Id: I2f8925ea26a4fb5419226265c579242889e2a506
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89663
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Diffstat (limited to 'icon-themes/elementary/cmd')
0 files changed, 0 insertions, 0 deletions