Bug 182247 - First input character on calendar view is always ASCII
Summary: First input character on calendar view is always ASCII
Alias: None
Product: Fedora
Classification: Fedora
Component: evolution
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Mayank Jain
QA Contact:
Keywords: i18n
Depends On:
Blocks: 208800
TreeView+ depends on / blocked
Reported: 2006-02-21 12:51 UTC by Akira TAGOH
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2007-04-27 08:21:39 UTC

Attachments (Terms of Use)
Patch (2.92 KB, patch)
2006-11-06 11:20 UTC, Mayank Jain
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Bugzilla 332026 None None None Never

Description Akira TAGOH 2006-02-21 12:51:05 UTC
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):

How reproducible:

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.

Comment 1 Mayank Jain 2006-05-24 09:37:41 UTC
(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?

Comment 2 Akira TAGOH 2006-05-24 09:49:09 UTC
Yes. that's why I didn't describe type enter say. follow the above step as is.
you will see the same problem then.

Comment 3 Mayank Jain 2006-05-24 10:53:47 UTC
upstream bug - http://bugzilla.gnome.org/show_bug.cgi?id=332026

Comment 4 Jong Bae KO 2006-06-15 08:58:52 UTC
------- Additional Comments From majain@redhat.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?


Comment 5 Mayank Jain 2006-08-14 09:55:36 UTC
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

Comment 6 Mayank Jain 2006-08-16 12:53:38 UTC
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

Comment 7 Mayank Jain 2006-10-13 11:03:53 UTC
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?

Comment 8 Matthew Barnes 2006-10-13 15:02:33 UTC
Mayank, I'm not at all familiar with this part of the code, but it sounds like
an interesting idea.

Comment 9 Mayank Jain 2006-11-06 11:20:22 UTC
Created attachment 140448 [details]

Comment 10 Mayank Jain 2006-11-06 11:22:01 UTC
Oops, sorry Matthew for moving to modified...

Comment 11 Matthew Barnes 2006-11-06 17:10:09 UTC
Patch applied to evolution-2.9.1-3.fc7.

Comment 12 Mayank Jain 2006-11-07 05:32:33 UTC
Thanks :)

Comment 13 A S Alam 2007-04-27 08:21:39 UTC
with ja_JP, aka is working ok, when goto send slot, it is shown without ASCII.

tested with following version:

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