Created attachment 44135 [details]
screenshot in the ja locale

Also reported downstream here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131227

Yong, can you take a look at this bug?

It seems that e-day-view.c::e_day_view_do_key_press () does not pass this key
press to gtk immodule.

--- e-day-view.c.orig   2004-11-30 11:17:51.000000000 +0800
+++ e-day-view.c.new    2005-04-26 18:10:10.550333288 +0800
@@ -5761,8 +5761,27 @@ e_day_view_do_key_press (GtkWidget *widg

        cal_component_get_uid (comp, &uid);
        if (e_day_view_find_event_from_uid (day_view, uid, &day, &event_num)) {
+               gboolean im_handled = FALSE;
+               EDayViewEvent *edv_event = NULL;
+               GtkIMContext *im_context = NULL;
+
+               if (day == E_DAY_VIEW_LONG_EVENT) {
+                       edv_event = &g_array_index (day_view->long_events,
EDayViewEvent,
+                                                   event_num);
+                } else {
+                       edv_event = &g_array_index (day_view->events[day],
EDayViewEvent,
+                                                   event_num);
+                }
+
+               if (edv_event->canvas_item)
+                       g_object_get (G_OBJECT (edv_event->canvas_item),
+                                     "im_context", &im_context,
+                                     NULL);
+
+               im_handled = im_context? gtk_im_context_filter_keypress
(im_context, (GdkEventKey*)event): FALSE;
+
                e_day_view_start_editing_event (day_view, day, event_num,
-                                               initial_text);
+                                               im_handled? NULL: initial_text);
        } else {
                g_warning ("Couldn't find event to start editing.\n");
        }

Suresh, could you please look at this patch? 

And, if iiim is used as the im module of gtk, gtk_im_context_filter_keypress ()
always return true (even before the IM is activated by ctrl+space), while xim
works fine in this case.

Hi Yong,
From a quick look I think similar issues may be there in week/month views, did
you test them ?

I have found some weird behaviours with month view when trying to input
japanese. Check it, I think we need to have a fix for all those calendar input
issues together.

Pl. let me know if you need any help, I will be away for a while on a vacation,
but ofcouse if this one do affect all views we can make it a stopper and fix it
in one of the later builds in  Cinnabar itself.

Sorry for those comments about Cinnabar, I just forgot this is gnome bugzilla. :(

Hi, Suresh,

I just found this fix also affects "Work Week" view. While weekly and monthly
view don't have this problem. :)

just tried this on evolution 2.5.90 and *this* behavior has been gone. but another problem appears to me. first character after clicking another timeslot during preediting is always ASCII, but second one is entering into the preedit.

my previous comment was possibly false alarm. this problem still appears on 2.5.90. but why I haven't seen is, I used the global IC feature on scim to share the IC between applications. sorry for confusion.

Created attachment 65213 [details] [review]
Another patch

Call reset_layout() when disconnecting signals to IMContext and draw preedit string only when connecting signals to IMContext.

This patch includes bug 341354. (memory leak fix)

I think my patch works fine about this bug, but there is another bug that the preedit string (not commited yet) does not appear when focus changes to other EText.

Created attachment 65816 [details] [review]
Patch to tackle preedit buffer problem

Hi, this patch seemingly removes the preedit buffer duplication problem.
Kindly have a look.

Thanks,
Makuchaku

(In reply to comment #14)

The document of gtk_im_context_reset in GTK+ Reference Manual is this:

"This will *typically* cause the input method to clear the preedit state."

Your patch does not work well in some cases.

Hi,

What can be such cases? I would love to know & improve my patch.

Thanks,
Makuchaku

(In reply to comment #16)

Implementation of gtk_im_reset depends on im module. In other words, application (Evolution in this case) should not expect preedit clearance.

For the reason, solution of this issue is that EText widget does not draw preedit strings if not connected to IMContext. It is my patch solution.

(In reply to comment #17)
> For the reason, solution of this issue is that EText widget does not draw
> preedit strings if not connected to IMContext. It is my patch solution.
> 

Hi,

I applied your patch, which is essentially these two changes...

+	if (text->im_context_signals_registered)
+		insert_preedit_text (text);

AND

+	save_text->im_context_signals_registered = FALSE;
+	reset_layout (save_text);

After building evo, I was still able to reproduce the problem.

Am i missing something here?

Thanks,
makuchaku

Realy? 
I've never met the issue after my patch has applied.

After looking at gtk_im_context_reset documentation & its implementation in gtk code, i somwhat agree with your viewpoint.

But the problem still persists at my end. Shall i attach the e-text.c file?

Thanks :)
Makuchaku

BTW, i dont think the patch is already there in evo 2.7.2.1 build?

makuchaku, please provide a changelog entry with a reference to the bug id instead of adding a comment in the code. :-) thanks in advance...

Sure,

:)
Makuchaku

Adding harish in CC list.

Umm... I dont think the patch is working... I'm using Evo 2.7.4 (the patch is there) but I can still replicate the issue.

Can someone from QA please check...

thanks :)

srini, makuchaku, sorry but i am unable to test this, because this is about directly entering japanese characters into the day view - i am unable to try this as gnome's input method (in the context menu) does not work in this case. :-/

i would be happy if somebody else running a CJK locale could also test this. thanks a lot.

perhaps bug 264404 and bug 263731 are also related to this. note the attached patches.

makuchaku, what is your immodule?

I tested SCIM and my test im-module <http://bugzilla.gnome.org/show_bug.cgi?id=321310#c5>

Hi Hiroyuki,
I'm using SCIM on my machine. Does the patch works on your machine?

Andre, you dont need to log into ja_JP locale to test this, login with your usual locale, install Anthy for scim (scim-anthy), start evo, click on any day view text widget, hit "a" to make it editable, press <ctrl>+<space> to enable scim & type "aka" to enter japanese text.

If you are able to enter this text, you can very easily go ahead with QA :)

Regards,
Mayank

The issue you mention is exactly same as the screenshot in comment #1?

please attach screenshot on your environment.

Created attachment 69227 [details]
The problem screenshot

Hi, As marked, you can see that 
1) Preedit buffer is replicating
2) the variable preedit_len jumps from 0 to 6 as i beging typing "aka" in second text widget (after i typed "aka" in first, but did not commited the preedit).

I was using the code which had your patch applied.

Hiroyuki, refering to http://bugzilla.gnome.org/show_bug.cgi?id=264485#c17
I was looking at gtkentry.c for how its resetting the IM.

static void
gtk_entry_reset_im_context (GtkEntry *entry)
{
  if (entry->need_im_reset)
    {
      entry->need_im_reset = 0;
      gtk_im_context_reset (entry->im_context);
    }
}

I think we can also saftely rely on gtk_im_context to reset the preedit buffer.

What do you say?

Thanks,
Mayank

As far as I see your screenshot, it is not this bug. You say about that preedit string is preserved in new focused entry, don't you?

(In reply to comment #33)
> static void
> gtk_entry_reset_im_context (GtkEntry *entry)
> {
>   if (entry->need_im_reset)
>     {
>       entry->need_im_reset = 0;
>       gtk_im_context_reset (entry->im_context);
>     }
> }
> 
> I think we can also saftely rely on gtk_im_context to reset the preedit buffer.

Where is the relationship between resetting im context and clear preedit buffer in the code?

(In reply to comment #34)
> As far as I see your screenshot, it is not this bug. You say about that preedit
> string is preserved in new focused entry, don't you?
> 

The screenshot depicts that though preedit was cleared form the first text widget, it got replicated (& automatically inserted) in the secont text widget when i started editing it.

In the second text widget あかあ　appeared when i just typed "a".
Expected output was just あ

--
Makuchaku

Created attachment 69310 [details]
this will clear any doubts

I fetched e-text.c again from the cvs to nullify any effects i've had made to it & rebuilt evo.

The screenshot shows that the preedit is replicating across text widgets.

Hi,

I've created another patch which solves this problem at my end.
Hiroyuki, evoQA, can you kindly test it.

Thanks,
Makuchaku

Created attachment 69321 [details] [review]
Yet another patch

uses gtk_im_context_focus[in/out]

marking the older patches as "obsolete" to make a less confusion.

(In reply to comment #37)
> Created an attachment (id=69310) [edit]
> this will clear any doubts
> 
> I fetched e-text.c again from the cvs to nullify any effects i've had made to
> it & rebuilt evo.

I am confused what happened on your machine...
I am sorry, you did apply my patch?

Hi Hiroyuki, yes i did applied your patch & then created that screenshot.

Can a third person please confirm the result?

Andre: ping
Kharish: ping

(In reply to comment #39)
> Created an attachment (id=69321) [edit]
> Yet another patch
> 
> uses gtk_im_context_focus[in/out]

I understand what you want to do, but gtk_im_context_focus_xx has the same problem as gtk_im_context_reset() above I mentioned at comment #17. Their implement depends on im module. GTK+ document of gtk_im_context_focus_out() says :

The input method may, for example, change the displayed feedback or reset the contexts state to reflect this change.

But dont you think that with a focus out & focus in, gtk_im_context should also change focus? And afterall, it does resolves the problem :)

Created attachment 69562 [details] [review]
Combined patch

Ikezoe san, this is a combined patch & does works for me. focus in/out is anyways needed to notify im context.
I've obsoleted my patch, can you please check this one & then the QA team can proceed.

Thanks,
Makuchaku

(In reply to comment #44)
> But dont you think that with a focus out & focus in, gtk_im_context should also
> change focus? And afterall, it does resolves the problem :)

Yes, I think gtk_im_context_focus_in/out is needed in here.  In this sense, your patch is right, not wrong.  But your patch does not essentially fix this bug. Don't mistake it. 

I'm afraid of what this bug will not completely fix. 

(In reply to comment #45)
> Created an attachment (id=69562) [edit]
> Combined patch

It's better to be compliant with original coding style.
In your case, a space between function name and parenthesis is needed.

Oh, not an issue :)

BTW, the new patch does removes the problem. Please test it & then we can go ahead to commit it in the CVS HEAD.

Its been one long discussion for this bug :)

No problem atall...
I shall reupload the patch.

Created attachment 69634 [details] [review]
Patch updated to coding conventions

Updated the patch as per coding conventions used in evo code.

makuchaku, how about the following patch?


@@ -2249,6 +2250,7 @@ e_text_event (GnomeCanvasItem *item, Gdk
                                                                              0, 0, NULL,
                                                                              NULL, text);
                                        text->im_context_signals_registered = FALSE;
+                                       reset_layout (text);


Please test it without your change. This bug completely can not be fix without your help, I think.

Is it the patch in http://bugzilla.gnome.org/show_bug.cgi?id=264485#c12 ?

Diff after applying the patch comment #12.

okay, let me comment out my focus in/out lines & then test.

I know your patch works fine on your evironment, and my environment. But I repeat it is not essential solution for this bug.  My explanation might be bad...

Oh, dont worry about the explanation part, i've got your point.

However, i just tested with your patch & the input is replicating. I'm also attaching my e-text.c just for your reference. It does contain other changes which i did for bug#348638 but i dont think it should be causing any problem.

Thanks,
Makuchaku

Created attachment 69637 [details]
My e-text.c

The other changes irrelevant to this bug have been commented out in e_text_draw

Ugh! I do not want to read whole code. Please attach diff.

hehe, the function of interest is e_text_event & e_text_draw, just search :)
I attached the full file just in case you wanted to check what all other changes i might be doing :)

I don't understand what you want to do. Diff file shows clearly what you changed...

Anyway I looked your code, and I found there is no line what I want you to add.

I attach the diff file. Please test it without any your local changes if you do not understand whole evo codes and behaviour.

Created attachment 69702 [details] [review]
update patch

Call reset_layout() in another place.

By the way, I tested your fix without any other changes on my home machine at last night, this bug was still happened.

Hi Ikezoe san,
I'm still able to reproduce the problem with _just_ this patch.
i've attached a diff of the file i'm using (diff'd against the cvs head of e-text.c).

Created attachment 69954 [details] [review]
cvs diff -u8p e-text.c

This is NOT any patch, just showing that my e-text.c has _just_ hiroyuki's patch.
I am still able to reproduce the problem.

Hi Ikezoe san,
bad news...
Today I tested evolution with new IME - uim and both of our patches failed (Mine & yours).

have you tried your patch with any other IME?

I'm using the following to test

scim-1.4.4-25.fc6
scim-anthy-1.0.0-4.fc6
uim-1.1.1-2.fc6
[gnome@majain evolution]$ ./shell/evolution --version
Gnome evolution-2.8 2.7.90

Can you please check what are the verions you are using... just to confirm we are not going wrong as far as the version numbers are concerned.

Hi,

I tested Patch http://bugzilla.gnome.org/attachment.cgi?id=65816 (remember my first patch with gtk_im_reset_context?) with scim-anthy & uim (anthy) and both work perfectly (unable to reproduce the problem).

I think its now a strong case to consider gtk_im_context_reset function... there are two IME's that are working fine with it.

just tested my patch in http://bugzilla.gnome.org/attachment.cgi?id=65816 with kinput2 & there was absolutely no bug reproduction.

Now scim/uim/kinput2... all three work well with my patch.

Ikezoe san, what do you say?

Thanks.

Ikezoe San... ping

After applying the patch from http://bugzilla.gnome.org/show_bug.cgi?id=348638#c23 I can see that the preedit string stops replicating, but however remains in the preedit state when I try to switch between the text widgets... which is infact good.

I would give the patch in http://bugzilla.gnome.org/show_bug.cgi?id=264485#c61 a green signal, only when it is applied with the patch in http://bugzilla.gnome.org/show_bug.cgi?id=348638#c23

Thanks,
Mayank

I mean both http://bugzilla.gnome.org/show_bug.cgi?id=348638#c23 and http://bugzilla.gnome.org/show_bug.cgi?id=264485#c61 should be applied together to rectify this bug.

I'm attaching the latest working patch...

Created attachment 70625 [details] [review]
Working patch for this bug

I'm not obsoleting any patches with this patch as Ikezoe san, I still need a go ahead from you regardin this patch.

Thanks,
Mayank

okay... finally installed scim-anthy-0.8.0-14 and scim-1.4.4-23 on my suse10.1.

so i am in day view. i click on 10h00 once to mark it. now i enter an "a". now i hit control+space. nothing happens/changes. did i really enable scim? anything i have missed here? :-/
please guide a stupid user like me. :-)

Hi Andre,

If you didn't saw SCIm getting activated, try running evolution like this...

$ GTK_IM_MODULE=scim evolution

Let me know if you face any further problem :)

Thanks,
Makuchaku

Hi makuchaku, 

I am sorry for my absence. 

Just take a look, your patch in #72 is reasonable for me.

Hi Ikezoe san :)
Good to see you back!

Finally we can move to close this bug :)

Andre: Hi, were you able to reproduce the bug & tried the patch in #72?

Thanks,
makuchaku

will try, takes another day though. :-)

i ran
         GTK_IM_MODULE=scim /opt/evo-cvs/bin/evolution-2.8
went to the calendar day view, entered an "a" and hit control+space, but nothing happens, tried this both with the patch in comment #72 applied and without it. :-/
i'm doing something totally wrong ehre, strange.

Okay, do some quick checks...

1) Run gedit & try activating scim from within it. You might need to right click in the  editor area, go to "Input Methods" section, select scim, hit ctrl+enter see.

2) Do the same steps with this
GTK_IM_MODULE=scim gedit
when gedit starts, focus the editor & hit ctrl+enter

3) Also, try this
open gnome-terminal
run "scim-restart"
Now try GTK_IM_MODULE=scim evolution

...i hope it works now :-)

something's definitely wrong with my setup, it seems. :-(
what could i expect if it would work? i could enter japanese, right?
in gedit in can select scim from the input methods section, but when i hit ctrl+enter nothing happens - at least i enter the normal latin letters when i type.

any other volunteers here in the CC list?

Andre... there is a catch with evo...
After focussing on a text widget, you first have to press a regular ascii char to put it in editing mode & then use ctrl+space combination to activate scim.

Just try again :) & make sure you run scim-restart before starting evo.

Wish you luck :)
Mayank

Andre ping... Did it worked?

i still wasn't successful to get this running here with my setup, sorry. seems to be a "suse vs. scim" issue. :-/
any other testers highly welcome.

Andre can you please make al patches in this bug apart from that in #72 as obsolete?

This would greatly aid the new tester :)

Thanks,
Mayank

sure :-)

I have tested the patch. The pre-edit string is not duplicated now. But the pre-edit string is copied to second widget when the focus is changed to second widget while the first widget is in edit mode. 

Steps
1) create two events say a in dayview.
2) In the first event widget enter the letters aka.
3) While the first event widget is in edit mode, move to second widget (make sure tooltip does not change the focus)
4) the pre-edit string entered in first widget is copied to second widget.

Another side effect is, 
1) select the first widget and enter a string
2) while it is in edit mode, move the mouse over another event to get the tooltip
3) Now try creating an event by typing in dayview in some are free area.
4) The character typed are still stored in first widget (select the first widget to see this).

This may have been fixed by bug #264404.  Can someone retest with 2.21.5?

not replicated anymore. 2.21.5 works for me.

Thanks.  Closing as FIXED.