Red Hat Bugzilla – Bug 182247
First input character on calendar view is always ASCII
Last modified: 2007-11-30 17:11:24 EST
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):
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.
it shows like <u>aã</u>
it should be <u>ãã</u>
This happens regardless of which IME people uses. but need to enable the global
(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 email@example.com 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?
Files & functions of interest...
widgets/misc/e-canvas.[ch] - e_canvas_key
e_text_event_processor_emacs_like_event - case GDK_KEY_RELEASE:
widgets/text/e-text.c - e_text_event
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...
A very weird idea caught me whili looking at the bug... cant say if its even
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?
Mayank, I'm not at all familiar with this part of the code, but it sounds like
an interesting idea.
Created attachment 140448 [details]
Oops, sorry Matthew for moving to modified...
Patch applied to evolution-2.9.1-3.fc7.
with ja_JP, aka is working ok, when goto send slot, it is shown without ASCII.
tested with following version: