GNOME Bugzilla – Bug 80023
GtkTextView passes wrong cursor location to IM
Last modified: 2011-02-04 16:11:59 UTC
If the text window is scrolled down, the cursor location is no longer correct. Also, the cursor width and height are always 0 in the current implementation. It is preferrable to set them to the right size, although it is not as critical as to set the location right.
Created attachment 15167 [details] [review] correct im_spot_location
Sorry, I send my patch before I comment..... Attached patch resolve two problems above. First problem ( scrolled down, cursor not right ) is easy.This can resolve by + area.x = area.x - text_view->xoffset; + area.y = area.y - text_view->yoffset; Second problem is difficult when we have preedit string. Preedit string handling is different from normal text, so it's unsolvable only by using "insert" iterator. I referred to GtkEntry, when making proposed patch, so this patch will works fine. At least, it works fine with my Janapse input method module.
I hope that this bug will be corrected in next release. Because this bug is quite serious for some immodule user. (at least, all japanese user will be affected.) If you don't understand about this problem, I'm ready to explain for more detail. If you say my patch is too dirty, I'll rewrite my patch.
This problem breaks CJK input severely.
I've forgotten to write some infomation. *Version I checked Gtk+2.2.1. *Reappearance procedure 0. Install uim & anthy. (I don't now other program which use gtk_set_cursor_location) If you have already installed them, you may fly this clause. Anthy is kana-kanji conversion engine. Uim is multilingual input method library. From Gtk+, uim can be treated as a collection of immodule. You should download anthy-3900 and uim-1620 from http://sourceforge.jp/projects/anthy/files/ I want to say you can install them only ./configure, make, make install... but they have a little problem. If anthy not work, you should add /usr/local/lib to LD_LIBRARY_PATH. 1. start gedit 2. select uim-anthy from immodule list 3. Input 'a' ( I recommend three times or more ) and press space some times. 4.Candidate Window should appear at lower left corner of preedit, but it appears at center of a right end. And I made screenshot of this bug, since this reappearance procedure is troublesome a bit. ( If you haven't install uim and anthy )
Created attachment 16327 [details] Screenshot of wrong cursor location
Created attachment 16329 [details] Screenshot of right cursor location.
The patch looks good to me with a few minors: - gtk_text_layout_get_im_spot_location should have a gtk-doc comment. e.g: /** * gtk_text_layout_get_im_spot_location: * @layout: a #PangoLayout * @area: location to store the cursor position * * Get the cursor position. Input methods may use this * location to provide the candidate choice or * some other auxiliary windows. **/ - coding styles. - SPACEs between fuction names and '(' or around '+' are missing in a few places. - need an indentation at the last line in the gtk_text_layout_get_im_spot_location. + gtk_text_layout_free_line_display (layout, display); Owen, how do you feel to commit this either in both branches or only in the HEAD?
I don't think the approach here is quite right; we should always be taking layout->preedit_cursor into account when getting the cursor positions. I think the right thing to do is in gtk_text_layout_get_cursor_locations() check if the iter passed in is at the same location as the cursor iter, and if so, account for layout->preedit_cursor() So, then the gtktextview.c changes can simply use gtk_text_layout_get_cursor_locations() instead of adding new API. We should add a private gtk_text_view_get_insertion_cursor_location() that gtk_text_view_get/set_virtual_cursor_pos and gtk_text_view_update_im_spot_location() all use, so that when bug 73307 is fixed, we only have to fix it in one place. The change here to pass the real y/height to the input method makes sense, but I think a width of 0 should be used. The width returned for Pango for a cursor location is most useful for determining whether it is a LTR or RTL cursor (RTL cursors have negative width) and could potentially confuse input methods.
Created attachment 17190 [details] [review] Proposed patch
does not seem this has a fix. When text area is scrolled down, candidate window shows far off from the spot, while with Tokunaga-san's patch, it shows at the spot.
Created attachment 17192 [details] screenshot - candiate window shows far off below from the spot location.
Created attachment 17194 [details] [review] Patch, including xoffset/yoffset correct
Forgot that there were two problems being fixed, not just the preedit one. The new patch should resolve both.
Looks fine to me, if it works
gtk_text_view_grab_focus is missing, so the build fails. If I add the current one in gtk-2.2, text widget in gtk-demo behaves weird. Each time when I click the 2nd text widget(larger one), it ramdamly jumps to middle of the text.
But, location of candidate window is good when scrolling down.
Created attachment 17197 [details] [review] Patch, hopefully working this time
I'm having trouble making clean patches since I have four GtkTextView changes in my tree, all mixed together. Hopefully this last attachment will have all of the right patches and none of the wrong patches.
Yep, seems working well, tested with gtk-demo, testtext, gedit and gnome-terminal/vte.
Thu Jun 5 16:12:54 2003 Owen Taylor <otaylor@redhat.com> #80023, Yao Zhang, TOKUNAGA Hiroyuki * gtk/gtktextlayout.c (gtk_text_layout_get_cursor_locations): Account for the preedit cursor offset if the iter passed in is at the same place as the insertion cursor. * gtk/gtktextview.c (gtk_text_view_get_cursor_location): Encapsulate getting the insertion cursor location. * gtk/gtktextview.c (gtk_text_view_update_im_spot_location): Pass the real y/height to the IM context. Take text_view->x/yoffset into account.