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 731190 - XIM input mode indicator does not work. (It shows black box, e.g.)
XIM input mode indicator does not work. (It shows black box, e.g.)
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Input Methods
3.13.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2014-06-04 06:03 UTC by ishikawa
Modified: 2017-09-02 15:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Buggy XIM mode indicator (47.93 KB, image/png)
2014-06-04 06:03 UTC, ishikawa
  Details
Proposed patch : modules/input/gtkimcontextxim.c (1.27 KB, patch)
2014-06-04 08:21 UTC, ishikawa
none Details | Review
XIM mode indicator works after the patch (88.48 KB, image/png)
2014-06-04 08:22 UTC, ishikawa
  Details
XIM status indicator when Japanese input is invoked to write Japanese text into Firefox browser (gtk-3.0 version is used locally) (244.47 KB, image/png)
2017-09-02 15:47 UTC, ishikawa
  Details

Description ishikawa 2014-06-04 06:03:28 UTC
Created attachment 277855 [details]
Buggy XIM mode indicator

XIM input mode indicator does not work with gtk+ 3.

For example, I am uploading an image of gnome-terminal when
an XIM input module for Japanese input is used.

Please notice a small rectangle box at the lower-left corner.
It should show a Japanese character to indicate the input mode, but
currently it only shows a black box. Useless.


The problem started back in 2012 with gtk+ 2.21.6, I think.
I reported the issue under gtk+ 2 series in
Bug 696624 - Japanese (Korean/Chinese) XIM input mode indicator has not been working for TB and FF under linux. (with known solution) 

Maybe my title for the bug 696624  was not good. The problem is not limited to
thunderbird and firefox. It is general problem for any program that uses 
XIM input with libgtk+ 2.

(BTW, I identified the problematic patch.
https://bugzilla.gnome.org/show_bug.cgi?id=696624#c3

https://git.gnome.org/browse/gtk+/commit/modules/input/gtkimcontextxim.c?id=7f1801eae10b67fb8878eb562ed3614514b96097

)

Unfortunately, the problem is carried over to libgtk+ 3 series.

I am attaching the screen image that shows a problem with gnome-terminal when the XIM-compliant input method for Japanese.
gnome-terminal is liked with gtk++ 3 as shown by
   ldd `which gnome-terminal`
	linux-gate.so.1 (0xb77e1000)
	libvte2_90.so.9 => /usr/lib/libvte2_90.so.9 (0xb7722000)
	libgthread-2.0.so.0 => /usr/lib/i386-linux-gnu/libgthread-2.0.so.0 (0xb771f000)
	libgtk-3.so.0 => /usr/lib/i386-linux-gnu/libgtk-3.so.0 (0xb7257000)
	libgdk-3.so.0 => /usr/lib/i386-linux-gnu/libgdk-3.so.0 (0xb71d9000)
	libatk-1.0.so.0 => /usr/lib/i386-linux-gnu/libatk-1.0.so.0 (0xb71b5000)
	libgio-2.0.so.0 => /usr/lib/i386-linux-gnu/libgio-2.0.so.0 (0xb7033000)
        [...]
Note libgtk-3.so.0 output above. Debian's gtk package seems to be based
on 3.4.2 of gtk++ 3, but I am afraid that the current code has the same
issue: I noticed a bug in the source in git repository.


The mode indicator box shown by gtk++ 3 is as useless as with the case of firefox with libgtk2+ 
(atachment to bug 696624)
https://bug696624.bugzilla-attachments.gnome.org/attachment.cgi?id=239950

and the rectangle should show something like
(attachment to bug 696624).
https://bug696624.bugzilla-attachments.gnome.org/attachment.cgi?id=240021

The code in question has changed significantly and so I am not sure
what function corresponds to the buggy function in gtk++ 2 series, but
the following function is a suspect.

https://git.gnome.org/browse/gtk+/tree/modules/input/gtkimcontextxim.c#n1704

/* Draw the background (normally white) and border for the status window
 */
static gboolean
on_status_window_draw (GtkWidget *widget,
                       cairo_t   *cr)


Please note that the function misses a rectangle draw in comparison to
the function in gtk++ 2, on_status_window_expose_event()
 https://git.gnome.org/browse/gtk+/tree/modules/input/gtkimcontextxim.c?id=2.21.5#n1769.

I think on_status_window_draw missing drawing the border in the current form as well as using a wrong color.

The following is my idea of the corrected function: not tested yet. I need to download
the source files and re-create the library and replace im-xim.so and see if it works.

I think the background assumption is not quite correct (on Debian, for example).


/* Draw the background (normally white) and border for the status window
 */
static gboolean
on_status_window_draw (GtkWidget *widget,
                       cairo_t   *cr)
{
  GtkStyleContext *style;
  GdkRGBA color;

  style = gtk_widget_get_style_context (widget);

  /* text */
  gtk_style_context_get_color (style, 0, &color);
  gdk_cairo_set_source_rgba (cr, &color);
  cairo_paint (cr);

  cairo_rectangle (cr, 
                   0, 0,
                   gtk_widget_get_allocated_width (widget) - 1,
                   gtk_widget_get_allocated_height (widget) - 1);


  /* background */

  gtk_style_context_get_background_color (style, 0, &color);
  gdk_cairo_set_source_rgba (cr, &color);
  cairo_paint (cr);

  cairo_rectangle (cr, 
                   0+1 , 0+1,
                   gtk_widget_get_allocated_width (widget) - 2,
                   gtk_widget_get_allocated_height (widget) - 2);


  cairo_fill (cr);

  return FALSE;
}



TIA
Comment 1 ishikawa 2014-06-04 08:21:27 UTC
Created attachment 277856 [details] [review]
Proposed patch : modules/input/gtkimcontextxim.c
Comment 2 ishikawa 2014-06-04 08:22:51 UTC
Created attachment 277857 [details]
XIM mode indicator works after the patch

I have verified that the necessary change I outline in my original posting fixed the issue.
So I am uploading the fix to gtkimcontextxim.c and the screen dump that shows the mode indicator now works with the suggested change.

This problem is still in the latest git branch as well:
See https://git.gnome.org/browse/gtk+/tree/modules/input/gtkimcontextxim.c#n1706
(There is no rectangle draw with the bacground color (and that must come after the
text color drawing, I think.)

So I am going to change the information about the versions affected.
 

TIA
Comment 3 ishikawa 2014-06-05 04:16:07 UTC
I understand that XIM input method may be a stranger to many GTK users.

Given that XIM input method may be used only by people who need to handle scripts such as Arabic(?), Chinese, Korean, Japanese, some Indian scripts (there are many variants if I am not mistaken), Thai, etc., 
it may be difficult for the main developer community of GTK+ to test the patch, even.

Pity that bug 696624 still remains UNCONFIRMED, but the bug has bothered a lot of people more than two years.

So how can I get this bug to be promoted to, at least, the CONFIRMED status?
(The bug is for real, and the patch works as I show with the screen capture in the attachements.)

TIA
Comment 4 Daniel Boles 2017-09-02 07:18:53 UTC
Does this still occur in GTK+ 3.22?
Comment 5 Daniel Boles 2017-09-02 07:33:41 UTC
That looks like a no; see
https://git.gnome.org/browse/gtk+/commit/modules/input/gtkimcontextxim.c?h=gtk-3-22&id=c750cea4e57ed3bcb5ba7eada95d0be380aa2fe5

Let's see if we can get a similar fix picked to GTK+ 2.24 to fix Bug 696624.
Comment 6 ishikawa 2017-09-02 15:47:22 UTC
Created attachment 358992 [details]
XIM status indicator when Japanese input is invoked to write Japanese text into Firefox browser (gtk-3.0 version is used locally)

(In reply to Daniel Boles from comment #4)
> Does this still occur in GTK+ 3.22?

I tested this under Debian GNU/Linux.
It has /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-xim.so,
that is gtk-3.0 version is installed.

As you correctly pointed out in comment #5, the indicator is useful now (it does not have a clear border, but it is OK without it.).

You can see the indicator that SHOWS the text inside. This is good enough.

TIA
Comment 7 Daniel Boles 2017-09-02 15:58:49 UTC
Great, thanks for checking! I look forward to hearing what you think about the patch in Bug 696624 also.

It may not be too difficult to improve the theming of the status window if you wanted to open an enhancement request, but that's up to you.