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 303878 - candidate window position at 0,0 in Evolution Calendar
candidate window position at 0,0 in Evolution Calendar
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Calendar
2.2.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2005-05-12 05:32 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-12 02:15 UTC, Hiroyuki Ikezoe
none Details | Review
Adapted "proposed patch" to latest evo codebase (4.64 KB, patch)
2006-06-20 13:33 UTC, makuchaku (Mayank)
none Details | Review
Corrected patch (4.41 KB, patch)
2006-07-10 07:14 UTC, makuchaku (Mayank)
none Details | Review
revised patch (4.89 KB, patch)
2006-07-10 07:54 UTC, Hiroyuki Ikezoe
committed Details | Review

Description Lawrence Lim 2005-05-12 05:32:41 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
Comment 1 Nagappan Alagappan 2005-05-13 08:21:39 UTC
Adding keyword
Comment 2 Hiroyuki Ikezoe 2006-05-12 02:15:01 UTC
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.
Comment 3 Hiroyuki Ikezoe 2006-05-12 02:15:16 UTC
It's better to use with my patch in bug 264485.
Comment 4 Hiroyuki Ikezoe 2006-05-12 02:20:40 UTC
By the way, this bug is for Evolution itself, isn't it?
Comment 5 makuchaku (Mayank) 2006-06-20 13:30:33 UTC
Hi,

I've adapted your patch to the latest evo codebase (cvs) & added some comments. Kindly review it.

Thanks,
makuchaku
Comment 6 makuchaku (Mayank) 2006-06-20 13:33:00 UTC
Created attachment 67709 [details] [review]
Adapted "proposed patch" to latest evo codebase

Oops, sorry for not attaching the patch... here it is.
Kindly review.
Comment 7 André Klapper 2006-06-20 20:04:31 UTC
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?
Comment 8 makuchaku (Mayank) 2006-06-21 05:43:30 UTC
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
Comment 9 makuchaku (Mayank) 2006-06-21 06:56:29 UTC
Oops, I think i forgot the changelog.
Can the maintainer please add it with Hiroyuki's name.
Thanks.
Comment 10 André Klapper 2006-07-08 13:39:38 UTC
Hiroyuki: ping :-)
Can you please have a look at the modified patch?
Comment 11 Hiroyuki Ikezoe 2006-07-10 00:34:55 UTC
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.
Comment 12 Hiroyuki Ikezoe 2006-07-10 00:43:11 UTC
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.

Comment 13 Hiroyuki Ikezoe 2006-07-10 02:19:46 UTC
Makuchaku, why did you remove "static" from declaration of function? 
What is the aim?
Comment 14 makuchaku (Mayank) 2006-07-10 06:17:50 UTC
Oh, I might have missed it out. I shall re-upload the correct patch with static added & /**/ comments style.

Thanks for the review :)
Comment 15 Hiroyuki Ikezoe 2006-07-10 06:34:25 UTC
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.
Comment 16 makuchaku (Mayank) 2006-07-10 07:14:26 UTC
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
Comment 17 Hiroyuki Ikezoe 2006-07-10 07:51:16 UTC
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.
Comment 18 Hiroyuki Ikezoe 2006-07-10 07:54:27 UTC
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.
Comment 19 André Klapper 2006-07-19 20:13:36 UTC
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? :-)
Comment 20 makuchaku (Mayank) 2006-07-20 06:03:51 UTC
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
Comment 21 Matthew Barnes 2007-08-23 20:37:11 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 34081).