GNOME Bugzilla – Bug 303877
candidate window position at 0,0 in Evolution Task
Last modified: 2007-08-23 20:47:28 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. How reproducible: Always Steps to Reproduce: 1. LANG=ja_JP.UTF-8 evolution 2. Go to task list 3. Go to new task entry in the widget 4. Type "sushi", space, space 5. observe rthe 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: IIIMF is the input method used.
Lawrence: Can you please try with latest version ? Adding keyword.
Created attachment 65359 [details] [review] proposed patch Call gtk_im_context_set_cursor_location, the same way as bug 303878.
Can somebody change this bug to appropriate product(i.e evolution)?
harish: *poke*?
Created attachment 68707 [details] [review] revised patch * use gnome_canvas_get_scroll_offsets instead of gtk_layout_get_vadjustment etc. * subtract editing offset from candidate window position
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 34082).