Updates:
Status: Started
Cc: [email protected]
Comment #4 on issue 902 by takao.fujiwara1: Preediting becomes impossible
by receiving many incorrect signals from ibus-daemon
http://code.google.com/p/ibus/issues/detail?id=902
Attached the candidate patch.
The "mode" I said means 'typing_method' and 'input_mode' properties.
OK, I got it. My check was a little wrong.
but couldn't check this issue because language bar didn't appear at all,
unfortunately
Yes, the latest ibus doesn't show language bar by default. However you
could change
the behavior with ibus-setup command.
and confirmed that the input context receives the many incorrect signals
'UpdatePreeditText'
OK, I checked ibus receives the signal when typing_mode is changed.
I think sending preedit text "" is right in case preedit is changed.
I cannot reproduce endless events when I keep pressing Ctrl + '/' so I may
not
understand your problem yet.
But I agree not to send 'UpdatePreeditText' when the preedit length is zero.
The patch checks the preedit length before self.__reset() is called.
If you could confirm your problem is fixed with the patch, it would be
great.
I'll commit the patch next Monday. Probably I will release the new tarball
next month
or later since I don't see critical endless events.
Regarding to ibus-skk, CC'ing the maintainer.
It seems I could change input_mode when I type 'q' key with
INPUT_MODE_TRANSITION_RULE.get().
Attachments:
ibus-anthy-902-invalidate-preedit-len.patch 3.0 KB
--
You received this message because you are subscribed to the Google
Groups "ibus-devel" group.
iBus project web page: http://code.google.com/p/ibus/
iBus dev group: http://groups.google.com/group/ibus-devel?hl=en
