+++ This bug was initially created as a clone of Bug #150077 +++ Description of problem: At the moment, it is not possible to commit ja characters with Enter using CannaLE. Version-Release number of selected component (if applicable): evolution-2.0.2-8 evolution-data-server-1.0.2-4 iiimf-le-canna-12.1-10.EL How reproducible: Always Steps to Reproduce: 1.in g-t, LANG=ja_JP.UTF-8 evolution 2.select Calendar 3.click on any of the time slot 4.press a, backspace 5.ctrl-space 6.sushi 7.enter Actual results: Blank, unable to commit the ja character Expected results: Able to commit the ja char Additional info: Only exist for ja locale. Tried zh_*/ko and other indic locales as well.
Sorry new version for FC4: Version-Release number of selected component (if applicable): evolution-2.2.1.1-2 evolution-data-server-1.2.1-1 iiimf-le-canna-12.1.1-11.svn2435 It seems like evolution e-cal does not let IM to filter the enter properly.
Also determined for certain input mode in zh_TW, similar situation of not able to commit traditional chinese characters will occur. Take for example in Cang Jie mode of iiimf-le-xcin, it is not possible to commit a character from the candidate window using Enter. However, it is possible to commit the character using number as selection. Steps to reproduce: 1.in g-t, LANG=zh_TW.UTF-8 evolution 2.select Calendar 3.click on any of the time slot 4.press a, press enter Actual Result: Unable to commit the character Another scenario which will commit the character to the time slot. Steps to reproduce: 1.in g-t, LANG=zh_TW.UTF-8 evolution 2.select Calendar 3.click on any of the time slot 4.press a, press 1 Actual Result: Character gets committed to the time slot.
It is "enter" that evo does not pass to gtk im context and it is affecting couple of LEs. Users cannot able to input properly. Updating the summary.
I'm now looking into this problem, this is my analysis. Loosely the key event flow on the calendar component is (ECanvas *)->e_canvas_key ==(as "event" event)==> (EDayView *)->e_day_view_on_text_item_event ==> (EText *)->e_text_event. and basically gtk_im_context_filter_keypress is called on EText widget as it handles the real text. When you press Enter, EDayView will changes the focus from EText to EDayView itself forcibly to be able to stop editing by Enter. otherwise new line will be appeared on EText, I suppose, but anyway. However it's really a bad design because you can't call gtk_im_context_filter_keypress with the same keyevent because IM doesn't know if it's duplicated key event or not and IM shouldn't mind it - this problem could be gone with checking by gtk_im_context_filter_keypress before changing focus with GDK_Return so that basically it should be filtered by IM. but multiple gtk_im_context_filter_keypress calling causes the infinite key event loop somehow. I don't know why. but I'm sure it's caused by this so that I can see this problem on simple code with GtkEntry. Anyway, I'd just suggest to fix this: 1. not to mind GDK_Return to stop editing, replace EText to EEntry say. I haven't tried this, though. just guessing 2. process the keyevent on EText first anyway and make a signal or bind a key to take care of GDK_Return.
Created attachment 114473 [details] initial patch to be able to commit the string with Enter.
Created attachment 114474 [details] another patch for gal
This problem should be solved by above two patches. but there is a problem I know with these. when you edit an entry again, you will see a new line which was made by Enter, because editing was stopped after processing something on EText.
Created attachment 114494 [details] patch for gal, including forgot changes just updated a patch for gal so that I forgot to include the necessary changes.
Created attachment 114547 [details] patch for evolution, including a line feed fix. This patch will fixes a problem I mentioned in Comment#7.
Created attachment 114548 [details] patch for evolution, including a line feed fix. ugh, forgot to do garbage collection of arch.
Created attachment 114564 [details] updated patch for evolution, also including similar fix for EWeekView
Thanks for these patches. My first thought is that attachment 114494 [details] changes the EText API/ABI: E_TEXT_KEYPRESS signal gains a boolean return type. Have you checked for any/all usages of this signal?
Created attachment 114616 [details] updated patch for gal, also including API change in e-text.h Yes, tried to find its usages from Evolution related components which depends on libgal2 (evolution, evolution-exchange) and the products which does/did depend on gal (E_TEXT_KEYPRESS was available since 1.99.3) like gtkhtml3, mysql-query-browser and gnomesword - which depended on older gal package on Debian. Also tried to google it, I couldn't find any of this usage. I just wonder if this is a popular signal so that it wasn't documented.
Tested with test package with patch from Comment #13, confirm xcin and canna LE both are able to commit characters using Enter. Thanks.
*** Bug 154362 has been marked as a duplicate of this bug. ***
Dave, how is your review on this patch for FC4 final?
I built with the two patches into dist-fc4-hold as: libgal2-2.4.2-5 evolution-2.2.2-7 I haven't had a chance to test these properly yet, so I'm unhappy about putting them in FC4 at the moment. The Evolution package also contains another change (removed static libraries that I believe were unnecessary).
Confirmed fixed with evolution-2.2.2-7 and libgal2-2.4.2-5 in dist fc4-hold.
The fix happened too late. Release this as a FC4 update a little later after evolution gains more bug fixes to make an update worthwhile.
Packages from fc4-hold did not flow through. dist-fc4 still contains the old packages which the bug exist. evolution-data-server-1.2.2-3 evolution-devel-2.2.2-5 evolution-connector-2.2.2-5 evolution-webcal-2.2.0-1 evolution-2.2.2-5 evolution-data-server-devel-1.2.2-3 libgal2-devel-2.4.2-4 libgal2-2.4.2-4
Tested with libgal2-2.4.2-5 from dist-fc5, confirm the bug has been fixed.
Tested with evolution-2.2.3-1.fc4 and libgal2-2.4.3-1.fc4 from dist-fc4-updates-candidate, confirm the bug has been fixed. Thanks.
The above packages has already pushed for updates.