Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 182247 - First input character on calendar view is always ASCII
First input character on calendar view is always ASCII
Product: Fedora
Classification: Fedora
Component: evolution (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mayank Jain
: i18n
Depends On:
Blocks: 208800
  Show dependency treegraph
Reported: 2006-02-21 07:51 EST by Akira TAGOH
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-04-27 04:21:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

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

  None (edit)
Description Akira TAGOH 2006-02-21 07:51:05 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):

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 05:37:41 EDT
(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 05:49:09 EDT
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 06:53:47 EDT
upstream bug - http://bugzilla.gnome.org/show_bug.cgi?id=332026
Comment 4 Jong Bae KO 2006-06-15 04:58:52 EDT
------- 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 05:55:36 EDT
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 08:53:38 EDT
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 07:03:53 EDT
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 11:02:33 EDT
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 06:20:22 EST
Created attachment 140448 [details]
Comment 10 Mayank Jain 2006-11-06 06:22:01 EST
Oops, sorry Matthew for moving to modified...
Comment 11 Matthew Barnes 2006-11-06 12:10:09 EST
Patch applied to evolution-2.9.1-3.fc7.
Comment 12 Mayank Jain 2006-11-07 00:32:33 EST
Thanks :)
Comment 13 A S Alam 2007-04-27 04:21:39 EDT
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.