Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 174143 - pre-edit buffer not emptied after IME deactivated
Summary: pre-edit buffer not emptied after IME deactivated
Alias: None
Product: Fedora
Classification: Fedora
Component: scim
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jens Petersen
QA Contact:
Depends On:
Blocks: FC5Target SCIM
TreeView+ depends on / blocked
Reported: 2005-11-25 04:01 UTC by Lawrence Lim
Modified: 2014-03-26 00:52 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2006-03-17 09:18:52 UTC

Attachments (Terms of Use)

Description Lawrence Lim 2005-11-25 04:01:33 UTC
Description of problem:
Currently, if the IME is deactivated while pre-edit buffer |= NULL, when the IME
gets activated again, what was in the pre-edit buffer before will show up.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce: ja locale start gedit application (not locale specific)
2.activate scim
3.enter 'aka'
4.deactivate by ctrl-SPACE
5.activate scim again
Actual results:
Pre-edit buffer not empty

Expected results:
Pre-edit buffer should be emptied

Additional info:
Tried with CJK IME with similar behaviour.

Comment 1 Qian Shen 2005-12-06 02:06:52 UTC
I have talked with Su Zhe about this bug. He said this trigger hot key should be
handled in IMEs. I think it means each IME should be update except it has
handled this hot key. 

I wrote a test patch, just make IC reset when the IME is deactived. It seems
work well. But Su Zhe think it's not a good way, because reset() has special usage.

Below is my patch for reference :

--- gtkimcontextscim.cpp.orig   2005-12-06 10:11:27.732624776 +0800
+++ gtkimcontextscim.cpp        2005-12-02 15:36:36.000000000 +0800
@@ -1256,8 +1256,10 @@
     if (hotkey_action == SCIM_FRONTEND_HOTKEY_TRIGGER) {
         if (!ic->impl->is_on)
             turn_on_ic (ic);
-        else
+        else {
             turn_off_ic (ic);
+            ic->impl->si->reset(); //qshen
+        }
         ret = true;
     } else if (hotkey_action == SCIM_FRONTEND_HOTKEY_ON) {
         if (!ic->impl->is_on)

Comment 2 Qian Shen 2005-12-06 02:30:25 UTC
I think it's better to handle this deactivate/activate hot key in frontend/gtkim
moudle, because it's a global setting for frontend. We can set it in SCIM setup
window | frontend | global setting. The common setting for this hot key is

SCIM gtkim moudle names this hotkey as SCIM_CONFIG_HOTKEYS_FRONTEND_TRIGGER, and
handles it in filter_hotkeys() . The X11 frontend has similar handling code for
this hotkey.

We konw that preedit string is managed by IC. Gtk-im transfer IC to SCIM, SCIM
transfer IC to IME instance. IME can be accessed through IME APIs, but the only
API to handle preedit string is reset() .

So there are 2 choices to handle this bug. One is using reset() in
frontend/gtkim module, Another is handling the hotkey in IME inside. 


Comment 3 Qian Shen 2006-01-04 02:29:40 UTC
I had a talk with James Su. He said the hotkey should be handled in IMEs. He
didn't accepted editing the front end module. 

Comment 4 James Su 2006-01-11 04:08:43 UTC
This behaviour should be implemented in each IMEngine.
When scim is deactivated, the focus_out () method will be invoked, then IMEngine
may do anything in this method, for example clearing the preedit string.

Comment 5 Jens Petersen 2006-01-11 07:24:31 UTC
Thanks for the comment James.  Are there any IMEs for which resetting
pre-edit is not desirable?

Comment 6 James Su 2006-01-11 08:04:11 UTC
AFAIK, some input methods provided by upcoming scim-m17n with m17n 1.3.x have
such behaviour.

Comment 8 Jens Petersen 2007-03-05 23:58:36 UTC
Patch has been reverted in Fedora devel since December.

Note You need to log in before you can comment on or make changes to this bug.