Description of problem: This problem appears when I use evolution with the global IC mode which is SCIM feature to share the IC between applications. even if I activate IM on a time slot and input some Japanese character say and click on another slot, first character is always ASCII. but next one is native character even without press ctrl+space. so it means IC recognizes IM is activated now. This is a bad behavior because it enforces people to press backspace to delete the unexpected character once. Version-Release number of selected component (if applicable): evolution-2.5.90-2.1 How reproducible: always Steps to Reproduce: 1.make sure "Share the same input method among all applications" check box is enabled where is FrontEnd->Global Setup on scim-setup 2.run evolution with LANG=ja_JP.UTF-8 and open a calendar view. 3.click a timeslot somewhere and input a say. 4. press ctrl+space and make sure the scim panel appears and shows and icon like "ã" 5. type aka 6. click on another time slot and type aka again. Actual results: it shows like <u>aã</u> Expected results: it should be <u>ãã</u> Additional info: This happens regardless of which IME people uses. but need to enable the global IC anyway.
(In reply to comment #0) > 5. type aka > 6. click on another time slot and type aka again. You mean before comitting the preedit string?
Yes. that's why I didn't describe type enter say. follow the above step as is. you will see the same problem then.
upstream bug - http://bugzilla.gnome.org/show_bug.cgi?id=332026
------- Additional Comments From majain 2006-06-13 05:53 EST ------- 0) user shares IM context between all apps from the IM setup panel. 1) user starts gedit, activates scim & selects anthy 2) switches to evo & tries inputting text in calendar day view 3) the first input char is still ASCII Since the first function IMHO thats called after the selected text widget is edited is e_text_event in e-text.c shouldnt the code check to see if the IM is already active & keep the relevant signals attached? Thanks, Mayank
Files & functions of interest... widgets/misc/e-canvas.[ch] - e_canvas_key e-utils/e-text-event-processor-emacs-like.c - e_text_event_processor_emacs_like_event - case GDK_KEY_RELEASE: widgets/text/e-text.c - e_text_event
Another finding... When control comes to e_text_event (e-text.c), signals to text->im_context gets registered there... we loose the first event as before its generated, signals are not registered. Hence a good place to register signals is at the place its referenced first... ie. e_text_set_property
A very weird idea caught me whili looking at the bug... cant say if its even remotely possible... EDayView converts coordinates from its top/main canvas (GnomeCanvas) & then using them, directs its input to the text widgets (GnomeCanvasItem) But since EDayView has no GtkIMContext associated with it, when, scim is activated & a key is pressed through it, EDayView has no way of getting that input. So if we can somehow add a GtkImContext object in the EdayView structure, we *might* be able to get the i18n input & then transfer it to the child text widget. Matthew... if you've studied the code related to this bug, what do you say? Tagoh san?
Mayank, I'm not at all familiar with this part of the code, but it sounds like an interesting idea.
Created attachment 140448 [details] Patch
Oops, sorry Matthew for moving to modified...
Patch applied to evolution-2.9.1-3.fc7.
Thanks :)
with ja_JP, aka is working ok, when goto send slot, it is shown without ASCII. tested with following version: evolution-2.10.1-4.fc7