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 303877 - candidate window position at 0,0 in Evolution Task
candidate window position at 0,0 in Evolution Task
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: general
2.6.x (obsolete)
Other Linux
: Normal normal
: Future
Assigned To: Srinivasa Ragavan
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2005-05-12 05:05 UTC by Lawrence Lim
Modified: 2007-08-23 20:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
proposed patch (4.75 KB, patch)
2006-05-13 02:59 UTC, Hiroyuki Ikezoe
none Details | Review
revised patch (5.00 KB, patch)
2006-07-10 08:26 UTC, Hiroyuki Ikezoe
committed Details | Review

Description Lawrence Lim 2005-05-12 05:05:25 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.
Comment 1 Nagappan Alagappan 2005-05-12 06:43:14 UTC
Lawrence: Can you please try with latest version ?

Adding keyword.
Comment 2 Hiroyuki Ikezoe 2006-05-13 02:59:25 UTC
Created attachment 65359 [details] [review]
proposed patch

Call gtk_im_context_set_cursor_location, the same way as bug 303878.
Comment 3 Hiroyuki Ikezoe 2006-05-13 03:01:57 UTC
Can somebody change this bug to appropriate product(i.e evolution)?
Comment 4 André Klapper 2006-07-08 01:30:26 UTC
harish: *poke*?
Comment 5 Hiroyuki Ikezoe 2006-07-10 08:26:21 UTC
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
Comment 6 Matthew Barnes 2007-08-23 20:47:28 UTC
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).