GNOME Bugzilla – Bug 303878
candidate window position at 0,0 in Evolution Calendar
Last modified: 2007-08-23 20:47:46 UTC
Distribution/Version: FC Description of problem: For all CJKI, users are required to select candidates from the candidate window. In evolution, this candidate window is always positioned at 0,0. As a result, it obstruct users from seeing what was typed earlier. It would be ideal if the candidate window is positioned below the cursor. Version-Release number of selected component (if applicable): evolution-webcal-2.2.0-1 evolution-2.2.2-5 evolution-data-server-1.2.2-2 evolution-devel-2.2.2-5 evolution-data-server-devel-1.2.2-2 evolution-connector-2.2.2-3 evolution-debuginfo-2.2.2-5 How reproducible: Always Steps to Reproduce: 1.LANG=ja_JP.UTF-8 evolution 2.Go to calendar 3.Select 12 AM in the widget 4.ctrl-space to activate LE 5.type: sushi <space> <space> 6.observe the position of the candidate window Actual results: candidate window block the user from seeing what was typed earlier Expected results: candidate window positioned below the cursor Additional info: Tested with iiimf-12.2-3
Adding keyword
Created attachment 65281 [details] [review] proposed patch Call gtk_im_context_set_cursor_location. I think bug 303877 will be fixed by the same way.
It's better to use with my patch in bug 264485.
By the way, this bug is for Evolution itself, isn't it?
Hi, I've adapted your patch to the latest evo codebase (cvs) & added some comments. Kindly review it. Thanks, makuchaku
Created attachment 67709 [details] [review] Adapted "proposed patch" to latest evo codebase Oops, sorry for not attaching the patch... here it is. Kindly review.
i'm kinda confused, we have a patch here and hiroyuki states that "it's better to use with the patch in bug 264485." combined? do they bite each other or should they both be applied?
Hi Andre, Its just that i tried applying hiroyuki's original patch... but due to changes to code base, only parts of it were getting applied. I've modified it & patched it against the latest code base. So hiroyuki's code is intact... just some little changes. Hiroyuki, can you please have a look at the modified patch? Thanks, Mkuchaku
Oops, I think i forgot the changelog. Can the maintainer please add it with Hiroyuki's name. Thanks.
Hiroyuki: ping :-) Can you please have a look at the modified patch?
I am sorry for my delay. I've been very busy, but anyway I will do work about evo all day today. I read makuchaku's code from now on.
I just take a look not tested yet. At first, thank you for your insertion of comments in code. But using "//" style comment is not good in C source code.
Makuchaku, why did you remove "static" from declaration of function? What is the aim?
Oh, I might have missed it out. I shall re-upload the correct patch with static added & /**/ comments style. Thanks for the review :)
One more. + if(preedit_string) + g_free (preedit_string); you does not need NULL check, gtk_im_context_get_preedit_string() returns always newly allocated string.
Created attachment 68702 [details] [review] Corrected patch Hi, i'm attaching the new corrected patch. Though its hand edited, but i've made sure not to mess up the line numbers. Thanks
makuchaku, I'm sorry I found the bug in my original patch. The bug is that candidate window position is not correct when the focus EText item is scrolloed. I attach the revised patch.
Created attachment 68704 [details] [review] revised patch changes from my previous patch * use gnome_canvas_get_scroll_offsets instead of gtk_layout_get_vadjustment etc. * subtract scroll offset of EText item from candidate window position * insert makuchaku's comments.
hmm... i would be pleased to see you both have a statement about the patch situation here - makuchaku, pleased with hiroyuki's patch? which of your patches is the patch to test? :-)
Hi Andre, I've tested hiroyuki's patch & its working fine. Since its the latest patch, please go ahead onto QA with it :) Regards, makuchaku
This area is not my strong suit but I was able to reproduce the problem by following the steps in comment #0 (using Anthy input method). The candidate window appears in the upper left corner of the screen. With the patch applied, the candidate window appears under the cursor as it should. Also, Red Hat is already shipping this patch in RHEL5, which means our fine QA team already tested and approved it. That's good enough for me. Committed to trunk (revision 34081).