GNOME Bugzilla – Bug 150052
input method candidate window should be a little off of the cursor location
Last modified: 2007-11-30 20:25:19 UTC
Version: pkg-config --modversion vte : 0.11.11 The problem: XIM or IIIM based input methods shows candidate list windows right on the cursor location on a vte or on a gnome-terminal, and hides the text at insersion point.(A snapshot will be attached). Expected behaviour: The candidate list windows should be a little (but not too far) apart from the insersion point so that the text being preeditted can be viewed during the user is selecting a candidate.
Created attachment 30513 [details] input method candidate window hiding text at insertion point
Created attachment 30519 [details] [review] add one-charracter line height to y coodinate to im cursor location XIM based input methods expect that x.y coorinate of the base line is given as XNSpotLocation. By adding one-line character height (rect.height) to rect.y to be set to gtk_im_context_set_cursor_location() will make candidate window location more apporopriate.
I don't think there is any rule that the candidate window of all immodule should have a window decoration. Some immodules might show candidates as a popup window with no window decoration. Does this patch make sense for such immodules too?
Hidetoshi? Comment on the previous comment?
Please respond to the question here.
I have never seen the candidate window without window frames so I'm not sure if we need to think that case. But I think most people want to fix this problem.
I think fixing the problem is more important, since most candidate windows do have frames. If someone wants to not use frames, and this patch requires further work for their situation, why not fix it when the issue comes up?
Created attachment 86474 [details] [review] updated patch that applies against head Here is an updated patch that applies against head.
Does this work ok even at the last line of the widget? What if we are fullscreen?
Created attachment 86567 [details] [review] Updated patch regarding to the comment #9 > Does this work ok even at the last line of the widget? What if we are fullscreen? I attached the updated patch. Normally the candidate window is shown under the cursor but If GdkWindow top left Y + cursor columns x char length + length of the candidate window is larger than the screen height, the candidate window is shown upper the cursor. However it seems vte cannot get the length of candidate window because it's managed by IM. So now I'm about to think this is a GTK XIM bug instead of VTE. I also noticed the cursor is overlaped in GTK XIM but not overlaped in IIIMF which is the default IM in Solaris JDS.
Takao, looking at our JDS build, we are still applying the patch #8 to our builds, not the updated patch #9. Should we be using your updated patch? If this is a GTK bug, should we stop trying to patch vte and fix this instead in GTK+?
Sorry, I forgot this bug. I'll get time in this week however probably I'll remove the internal vte patch after we separete the GNOME 2.22 builds from the GNOME 2.20 builds.
I investigated this issue. Sorry, my patch id=86567 is not correct. Patch id=86474 is the right fix. libX11.so: XSetICValues() im-xim.so: gtk_im_context_xim_set_cursor_location () libgtk-x11-2.0.so: gtk_im_context_set_cursor_location() libvte.so: vte_terminal_process_incoming() XSetICValues() needs to receive the coordinates at bottom left of the strings but this problem is that vte_terminal_process_incoming() always put the coordinates at top left of the strings then some of input methods does not work. The fix "+ terminal->char_height" puts the coordinate of the preedit correctly. This problem does not depends on the window frame. This problem also does not depends on the full screen of the client applications. It's a IM's task how to put the candidate window with the coordinate of the preedit. Since the font size are managed by each application, this is a VTE bug but not a GTK xim.
So, you still recommend the last patch?
Created attachment 99818 [details] [review] Updated patch to clarify I replaced my patch with Brian's patch to remove mine. Could you integrate the patch? Thanks.
I updated the bug report but it seems the notification mail was down. This is a test mail.
Very sorry for changing the solution again. Reading bug 158678 and 339367, this problem is GTK xim module. I overlooked gtk_im_context_set_cursor_location() has the rect parameter instead of (x,y) So adding the font height in gtk_im_context_xim_set_cursor_location() resolves both VTE and GtkTextView. Finally I think the patch of 339367 is right. Can we close this as duplicated of 339367?
Takao, if this problem is fixed without needing the patch, can you make sure to remove the patch from our Solaris spec-file build system. If other patches are needed to fix GTK+ or whatever, make sure those patches are added. Thanks.
Thanks! *** This bug has been marked as a duplicate of 339367 ***