Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 157505 - candidate window position at 0,0 in Evolution Calendar
Summary: candidate window position at 0,0 in Evolution Calendar
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: evolution
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Matthew Barnes
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 157506 FC4Update
TreeView+ depends on / blocked
 
Reported: 2005-05-12 05:33 UTC by Lawrence Lim
Modified: 2014-03-26 00:52 UTC (History)
3 users (show)

Fixed In Version: evolution-2.7.3
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-07-14 07:02:46 UTC


Attachments (Terms of Use)
I dont find any text hiding here... (deleted)
2006-05-16 10:54 UTC, Mayank Jain
no flags Details
Patch (deleted)
2006-06-20 13:33 UTC, Mayank Jain
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
GNOME Bugzilla 303878 None None None Never

Description Lawrence Lim 2005-05-12 05:33:24 UTC
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

Comment 1 Akira TAGOH 2005-05-20 07:05:48 UTC
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 23:53:08 UTC
Has this been filed upstream?

Comment 4 Lawrence Lim 2005-06-20 06:37:32 UTC
Yes and I have included it in the External Bugzilla References section in our bz
towards the bottom of the page.

<http://bugzilla.gnome.org/show_bug.cgi?id=303878>

Comment 6 Lawrence Lim 2005-10-10 23:20:01 UTC
(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-19 00:55:33 UTC
My bad. Should be Bug 157506 instead.

Comment 9 Mayank Jain 2006-05-16 10:54:41 UTC
Created attachment 129170 [details]
I dont find any text hiding here...

Comment 10 Mayank Jain 2006-05-16 10:57:17 UTC
As seen in the attached screenshot, the typed text is clearly visible. Lawrence,
can you please reconfirm this.

Thanks,
Mayank

Comment 11 Akira TAGOH 2006-05-17 02:02:09 UTC
(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 12:23:49 UTC
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 :

evolution-2.7.3-2
evolution-data-server-1.7.3-2
evolution-sharp-0.11.1-1
evolution-webcal-2.7.1-4

Tested on O.S. : Fedora Core Release 5.89 (Rawhide) i386.

Comment 13 Mayank Jain 2006-06-20 13:33:49 UTC
Created attachment 131195 [details]
Patch

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

QE, kindly test.

Thanks,
Mayank

Comment 15 Matthew Barnes 2006-06-26 17:35:22 UTC
Done - evolution-2.7.3-4

Comment 16 Mayank Jain 2006-06-27 05:22:02 UTC
Thanks Matthew.

Comment 17 A S Alam 2006-06-30 09:56:32 UTC
it is fixed for locale

test with envirnment:
-----------------
evolution-2.7.3-5
evolution-data-server-1.7.3-3
evolution-webcal-2.7.1-4
------------------

Comment 18 Mayank Jain 2006-07-13 09:19:09 UTC
Matt, Upstream has updated the patch, can you please have a look at it
http://bugzilla.gnome.org/show_bug.cgi?id=303878#c18

Comment 19 Matthew Barnes 2006-07-13 17:16:15 UTC
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 06:11:04 UTC
Thanks again :)

Comment 21 A S Alam 2006-07-14 07:02:46 UTC
working fine with following package:
---
evolution-2.7.4-2
---


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