After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 332026 - First input character on calendar view is always ASCII
First input character on calendar view is always ASCII
Status: RESOLVED OBSOLETE
Product: evolution
Classification: Applications
Component: Calendar
2.22.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2006-02-21 12:46 UTC by Akira TAGOH
Modified: 2013-08-26 11:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch for solving bug (3.00 KB, patch)
2006-12-20 10:39 UTC, makuchaku (Mayank)
none Details | Review
Patch from RHEL5 (3.23 KB, patch)
2007-08-27 21:23 UTC, Matthew Barnes
committed Details | Review

Description Akira TAGOH 2006-02-21 12:46:16 UTC
I'm using SCIM for my favorite Input Method and it has a feature to share Input Context between applications, so-called the global IC mode. on this mode, Bug#264485 (CJK input gets replicated in Evolution Cal) disappears. but it introduces another problem. it is, 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 say - ctrl+space is the default key to activate IM on SCIM.  So it means IC recognizes IM is activated now.
This is a bad behavior because this behavior enforces people to press backspace to delete the unexpected character once.

How to reproduce this problem:
1. make sure if scim and scim-anthy works say
2. run scim-setup and go to FrondEnd->Global Setup and turn on "Share the same input method among all applications" checkbox. press OK button then.
3. run evolution with LANG=ja_JP.UTF-8 locale say, and open a calendar view.
4. click a timeslot somewhere and input a say.
5. press ctrl+space and make sure the scim panel appears and shows an icon like "あ".
6. type aka
7. click on another timeslot and type aka again.

Actual Result:
it shows like <u>aか</u>

Expected Result:
it should be <u>あか</u>


step 4 is even a bug IMHO because I can't input Japanese from the first though.
Comment 1 makuchaku (Mayank) 2006-08-14 08:53:56 UTC
Downstream bug - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182247
Comment 2 makuchaku (Mayank) 2006-12-20 10:39:12 UTC
Created attachment 78679 [details] [review]
Patch for solving bug
Comment 3 André Klapper 2007-05-15 14:38:45 UTC
copying from downstream:

Comment #11 From Matthew Barnes on 2006-11-06
Patch applied to evolution-2.9.1-3.fc7.

Comment #13 From A S Alam on 2007-04-27 04:21
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

so is this safe to commit to upstream trunk? matthew, what do you think?
Comment 4 Matthew Barnes 2007-08-27 21:23:18 UTC
Created attachment 94459 [details] [review]
Patch from RHEL5

Here's the final patch we wound up going with for RHEL5.  I just verified that it applies cleanly and fixes the bug.  Also passed our internal QA and all that.

Any objections to me committing this?
Comment 5 Suman Manjunath 2007-08-28 03:51:11 UTC
Matthew, one little observation: won't there be a regression in week/month views? 
I guess, similar changes for (e_week_view_do_key_press), (e_week_view_start_editing_event) would fix that :-)
Comment 6 Chenthill P 2007-09-09 19:58:26 UTC
Fix has been committed to svn HEAD.
Comment 7 Akira TAGOH 2008-01-23 01:46:17 UTC
To confirm, has any released Evolution been applied this fix? I can still see this problem on 2.21.5
Comment 8 André Klapper 2008-01-23 02:28:00 UTC
the patch mentioned here has been committed and is included in 2.21.5:
http://svn.gnome.org/viewvc/evolution/trunk/calendar/gui/e-day-view.c?r1=34156&r2=34204
so perhaps it did not fix this issue.
Comment 9 Matthew Barnes 2008-03-11 00:36:27 UTC
Bumping version to a stable release.
Comment 10 André Klapper 2013-08-26 11:18:34 UTC
Using GNOME 3.8 and Russian hardware keyboard input via the dropdown in the top bar (IBus), I cannot reproduce the problem anymore. First character is Russian.

Closing as obsolete, but please reopen if this is still an issue in a recent Evolution version (3.8 or 3.6). Thanks!