GNOME Bugzilla – Bug 335796
Gtk accelerator key event can't be passed to other widgets properly when GTK_IM_MODULE=xim
Last modified: 2007-03-09 23:43:25 UTC
Please describe the problem: When use xim as Gtk im module, key events such as ALT-F can't pop up the main menu of any applications. Steps to reproduce: 1. export GTK_IM_MODULE=xim 2. gedit 3. press ALT-f Actual results: "f" is inserted into text buffer rather than menu is popped up. Expected results: Menu is popped up. Does this happen every time? Yes Other information:
Suggested fix: --- gtkimcontextxim.c~ 2005-07-01 02:42:44.000000000 +0800 +++ gtkimcontextxim.c 2006-03-24 14:05:01.120256000 +0800 @@ -756,6 +756,17 @@ buffer[num_bytes] = '\0'; + /* If the buffer is good enough to be insert to other widgets, + * we will detect the modifiers state and decide whether to discard + * this buffer, because things become worse. + * + * Maybe this fix can't work on some platforms. Need be confirmed. + * + */ + if (event->state & + (gtk_accelerator_get_default_mod_mask () & ~GDK_SHIFT_MASK)) + return FALSE; + result_utf8 = mb_to_utf8 (context_xim, buffer); if (result_utf8) {
Created attachment 61890 [details] [review] The patch for this bug.
*** Bug 335798 has been marked as a duplicate of this bug. ***
Can this patch be applied? It fixes bug 331369 for me on Solaris.
bug #331369 comment 29 contains a similar patch, which uses accel_mod_mask = gtk_accelerator_get_default_mod_mask() & ~(GDK_CONTROL_MASK | GDK_SHIFT_MASK); since it looks like ctrl can be handled by the IM.
(In reply to comment #5) > bug #331369 comment 29 contains a similar patch, which uses > > accel_mod_mask = gtk_accelerator_get_default_mod_mask() & ~(GDK_CONTROL_MASK > | GDK_SHIFT_MASK); > > since it looks like ctrl can be handled by the IM. No, it's not related IM. Keypress with control mask is handled appropriately by IM with XFilterEvent() before checking the accelerator modifier in both patches. The reason I removed CONTROL_MASK in bug #331369 comment #29 is that control characters seem checked afterward in gtkimcontextxim.c. result_utf8 = mb_to_utf8 (context_xim, buffer); if (result_utf8) { if ((guchar)result_utf8[0] >= 0x20 && result_utf8[0] != 0x7f) /* Some IM have a nasty habit of converting * control characters into strings */ { g_signal_emit_by_name (context, "commit", result_utf8); result = TRUE; } g_free (result_utf8); } The difference whether removing CONTROL_MASK or not is that keypress with ctrl modifier without producing control characters (like Ctrl-"1") becomes TRUE and "1" is committed in my patch, and becomes FALSE with the patch in comment #2. From the point of view about consistent behavior with gtk-im-context-simple (gtkimcontextsimple.c), the patch in comment #1 is fine I think. It has following code which returns FALSE with keypress with CONTROL_MASK. Please commit the patch in comment #2. I've confirmed it works file with uim and SCIM using Gedit. if (!have_hex_mods || (n_compose > 0 && !context_simple->in_hex_sequence) || (n_compose == 0 && !context_simple->in_hex_sequence && !is_hex_start) || (context_simple->in_hex_sequence && !hex_keyval && !is_hex_start && !is_hex_end && !is_escape && !is_backspace)) { if (event->state & (gtk_accelerator_get_default_mod_mask () & ~GDK_SHIFT_M ASK) || (context_simple->in_hex_sequence && context_simple->modifiers_dropped && (event->keyval == GDK_Return || event->keyval == GDK_ISO_Enter || event->keyval == GDK_KP_Enter))) { return FALSE; } }
2007-03-09 Matthias Clasen <mclasen@redhat.com> * modules/input/gtkimcontextxim.c (gtk_im_context_xim_filter_keypress): Don't commit modifier-adorned characters. (#331369, #335796, Lin Ma and others)
*** Bug 331369 has been marked as a duplicate of this bug. ***