Bug 157505 - candidate window position at 0,0 in Evolution Calendar
candidate window position at 0,0 in Evolution Calendar
Product: Fedora
Classification: Fedora
Component: evolution (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Matthew Barnes
: i18n, Reopened
Depends On:
Blocks: 157506 FC4Update
  Show dependency treegraph
Reported: 2005-05-12 01:33 EDT by Lawrence Lim
Modified: 2014-03-25 20:52 EDT (History)
3 users (show)

See Also:
Fixed In Version: evolution-2.7.3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-07-14 03:02:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
I dont find any text hiding here... (69.87 KB, image/png)
2006-05-16 06:54 EDT, Mayank Jain
no flags Details
Patch (4.64 KB, patch)
2006-06-20 09:33 EDT, Mayank Jain
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 303878 None None None Never

  None (edit)
Description Lawrence Lim 2005-05-12 01:33:24 EDT
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):

How reproducible:

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
Comment 1 Akira TAGOH 2005-05-20 03:05:48 EDT
I spent some times to fix this problem. but I have no idea ATM, because EText
itself doesn't have a GdkWindow and it's being rendered on the parent GdkWindow.
Basically Input Method gets a position from gtk_im_context_set_cursor_location()
and location of client window which was set by
gtk_im_context_set_client_window(). so generally you just need to consider the
relative position of cursor at the widget with gtk_im_context_set_cursor_location.
But on EText, where it's rendering depends on the behavior of the parent widget.
EText could gets its position from the parent widget, but it won't work properly
because the parent widget is in the scrolled widget and EText itself can't
assume that.
Comment 3 Dave Malcolm 2005-06-17 19:53:08 EDT
Has this been filed upstream?
Comment 4 Lawrence Lim 2005-06-20 02:37:32 EDT
Yes and I have included it in the External Bugzilla References section in our bz
towards the bottom of the page.

Comment 6 Lawrence Lim 2005-10-10 19:20:01 EDT
(In reply to comment #5)
> Fedora bug getting pulled into U3 proposed list.  Please clone to RHEL4 bug and
> explicitly place on U3 proposed list if plans are to fix in U3.

Bug 157596 was created and tagged U3 proposed.
Comment 7 Lawrence Lim 2005-10-18 20:55:33 EDT
My bad. Should be Bug 157506 instead.
Comment 9 Mayank Jain 2006-05-16 06:54:41 EDT
Created attachment 129170 [details]
I dont find any text hiding here...
Comment 10 Mayank Jain 2006-05-16 06:57:17 EDT
As seen in the attached screenshot, the typed text is clearly visible. Lawrence,
can you please reconfirm this.

Comment 11 Akira TAGOH 2006-05-16 22:02:09 EDT
(In reply to comment #10)
> As seen in the attached screenshot, the typed text is clearly visible. Lawrence,
> can you please reconfirm this.

Apparently you are confused. this is saying that the candidate window doesn't
follow at the bottom of the cursor.
Comment 12 Satyabrata Maitra 2006-06-20 08:23:49 EDT
This bug is not fixed yet. It still exists. Candidate window is not appearing at
the bottom of the cursor. Tested on the package versions :


Tested on O.S. : Fedora Core Release 5.89 (Rawhide) i386.
Comment 13 Mayank Jain 2006-06-20 09:33:49 EDT
Created attachment 131195 [details]

Modified an upstream patch, documented it & adapted it to latest codebase.
Things work perfect at my end now.

QE, kindly test.

Comment 15 Matthew Barnes 2006-06-26 13:35:22 EDT
Done - evolution-2.7.3-4
Comment 16 Mayank Jain 2006-06-27 01:22:02 EDT
Thanks Matthew.
Comment 17 A S Alam 2006-06-30 05:56:32 EDT
it is fixed for locale

test with envirnment:
Comment 18 Mayank Jain 2006-07-13 05:19:09 EDT
Matt, Upstream has updated the patch, can you please have a look at it
Comment 19 Matthew Barnes 2006-07-13 13:16:15 EDT
Updated the patch in Rawhide - evolution-2.7.4-2

Changing component from evolution-data-server to evolution.
Comment 20 Mayank Jain 2006-07-14 02:11:04 EDT
Thanks again :)
Comment 21 A S Alam 2006-07-14 03:02:46 EDT
working fine with following package:

Note You need to log in before you can comment on or make changes to this bug.