rpms/ibus-hangul
5
0
Fork 0
Code Issues Pull Requests Releases Activity

Resolves: RHBZ#1296121

Browse Source
This commit is contained in:
Peng Wu 2018-07-03 15:29:10 +08:00
parent 7221192109
commit 54f2714469
2 changed files with 88 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

80
ibus-hangul-fixes-order-problem.patch Normal file
View File

@ -0,0 +1,80 @@
commit 1ddfdc1219586ed7ca11bed38827b38dacd88aef
Author: Choe Hwanjin <choe.hwanjin@gmail.com>
Date: Sat Dec 31 01:04:22 2016 +0900
Fix wrong space order problem
With IBUS_ENABLE_SYNC_MODE=1 option,
'rksk ' is translated '가 나'.
It's caused by limitations of IBus implementation.
IBus can not send a result of other function inside a function
in sync mode. The results of other functions will be delayed until
the current function ends.
This makes ibus-hangul do wrong.
We solve this problem by forwarding key event.
It may be a hack, but we can not help it.
That's the limitation of the framework.
https://github.com/choehwanjin/ibus-hangul/issues/42
diff --git a/src/engine.c b/src/engine.c
index bd009cb..960bedc 100644
--- a/src/engine.c
+++ b/src/engine.c
@@ -1190,7 +1190,54 @@ ibus_hangul_engine_process_key_event (IBusEngine *engine,
ibus_hangul_engine_flush (hangul);
}
- return retval;
+ /* We always return TRUE here even if we didn't use this event.
+ * Instead, we forward the event to clients.
+ *
+ * Because IBus has a problem with sync mode.
+ * I think it's limitations of IBus implementation.
+ * We call several engine functions(updating preedit text and committing
+ * text) inside this function.
+ * But clients cannot receive the results of other calls until this
+ * function ends. Clients only get one result from a remote call at a time
+ * because clients may run on event loop.
+ * Clients may process this event first and then get the results which
+ * may change the preedit text or commit text.
+ * So the event order is broken.
+ * Call order:
+ * engine client
+ * call process_key_event
+ * begin process_key_event
+ * call commit_text
+ * call update_preedit_text
+ * return the event as unused
+ * receive the result of process_key_event
+ * receive the result of commit_text
+ * receive the result of update_preedit_text
+ *
+ * To solve this problem, we return TRUE as if we consumed this event.
+ * After that, we forward this event to clients.
+ * Then clients may get the events in correct order.
+ * This approach is a kind of async processing.
+ * Call order:
+ * engine client
+ * call process_key_event
+ * begin process_key_event
+ * call commit_text
+ * call update_preedit_text
+ * call forward_key_event
+ * return the event as used
+ * receive the result of process_key_event
+ * receive the result of commit_text
+ * receive the result of update_preedit_text
+ * receive the forwarded key event
+ *
+ * See: https://github.com/choehwanjin/ibus-hangul/issues/40
+ */
+ if (!retval) {
+ ibus_engine_forward_key_event (engine, keyval, keycode, modifiers);
+ }
+
+ return TRUE;
}
static void

9
ibus-hangul.spec
View File

@ -3,7 +3,7 @@
Name: ibus-hangul
Version: 1.5.0
Release: 12%{?dist}
Release: 13%{?dist}
Summary: The Hangul engine for IBus input platform
License: GPLv2+
Group: System Environment/Libraries
@ -19,6 +19,9 @@ Patch2: ibus-hangul-python3.patch
# Upstreamed: https://github.com/choehwanjin/ibus-hangul/pull/34
Patch3: ibus-hangul-autogen-remove-gettext.patch
# Pulled from upstream
Patch4: ibus-hangul-fixes-order-problem.patch
BuildRequires: gettext-devel, automake, libtool
BuildRequires: intltool
BuildRequires: libtool
@ -43,6 +46,7 @@ libhangul.
%patch1 -p1 -b .setup-abspath
%patch2 -p1
%patch3 -p1
%patch4 -p1
# autopoint -f
# AUTOPOINT='intltoolize --automake --copy' autoreconf -fi
@ -118,6 +122,9 @@ desktop-file-validate ${RPM_BUILD_ROOT}%{_datadir}/applications/ibus-setup-hangu
%{_datadir}/icons/hicolor/*/apps/*
%changelog
* Tue Jul 3 2018 Peng Wu <pwu@redhat.com> - 1.5.0-13
- Resolves: RHBZ#1296121
* Wed Feb 07 2018 Fedora Release Engineering <releng@fedoraproject.org> - 1.5.0-12
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild