GNOME Bugzilla – Bug 457086
numpad does not work when the Thai-Lao input method is used
Last modified: 2009-03-02 18:35:03 UTC
Please describe the problem: When use GTK+ Language Selector with Thai(th) the numpad does not work Steps to reproduce: 1. use GTK+ Language Selector with Thai(th) 2. use GIMP Actual results: use GTK+ Language Selector with Thai(th) Expected results: use GTK+ Language Selector with English(C) Does this happen every time? yes Other information: I'm teach friends to use GIMP but they are not happy with English and this problem they want to use Thai and numpad too
This seems to be a problem in GTK+ rather than in GIMP. But please be a bit more specific about what does not work: - Does the numeric keypad work when you use the "C" locale (English)? - What do you mean exactly by "does not work"? Does this mean that nothing happens when you press a key on the numeric keypad? - Do you have the same problems with or without Num Lock on? Please answer all these questions so that we can understand your problem.
- Does the numeric keypad work when you use the "C" locale (English)? yes - What do you mean exactly by "does not work"? Does this mean that nothing happens when you press a key on the numeric keypad? yes - Do you have the same problems with or without Num Lock on? both
What operating system are you using? Which version of GTK+ ?
(In reply to comment #3) > What operating system are you using? Which version of GTK+ ? > I'm test it on windows xp sp2 and windows 2k, and that's have same ploblem version of gtk+ 2.10.13
Ignoring keypad numbers is because of the "Thai-Lao" input method that GTK+ uses in the Thai locale. Whether it is on purpose or not I have no idea. The Thai-Lao input method was added as a fix to bug #81031. Theppitak, do you know?
This bug sounds similar to Bug #438261, which is supposed to be fixed in GTK+ 2.10.13. However, I only tested it on Linux when fixing that bug. Could somebody figure out how to adapt Attatchment #88144 to Windows? What's needed are the masks for CapsLock and NumLock modifiers.
Well, I suppose the question in comment #5 has been answered in comment #6. I am thus reopening. Feel free to close if this issue is obsolete by now. Just for your convenience, it's attachment #88144 [details] (it should be a proper link now...)
Created attachment 128351 [details] [review] Don't count character-generating KPs as context-lost keys I've tested it again with trunk GTK+. Keypad keys appear to fail to generate characters on Linux, too. But a locally-developed third-party module, gtk-im-libthai, does not have this problem. So, I check the differences. And this patch is another missed change found. This patch solves the problem for me on Linux.
Yay a patch :) While it looks simple, I don't understand it ;-) But maybe does Tor :) *poke*
Well, the modules/input/gtkimcontextthai.c file is used as such for Thai also on Windows, so if the patch works for Linux, it presumably works for Windows, too. (That said, I am not sure whether we *should* use GTK+'s locale-specific input method contexts also on Windows. Probably we ideally should just let Windows built-in stuff handle things, or at least make sure GTK+ works like the Windows keyboard layout in question does. (And let GTK+ extend the built-in capability in the cases where it doesn't disagree with reasonable user expectation.) However, this is more complex than it sounds. Compare for instance to bug #569581, which is about having the Windows built-in mechanisms work for the relatively simple US-International keyboard. I imagine for Thai more complex issues would show up.) Anyway, sure, if this problem happens on Linux too, and the above patch helps, then indeed it should be committed, I would say. Changing the component from "win32" to "input-methods" and OS to "All".
In case some explanation is needed for the patch: In gtkimcontextthai.c, gtk_im_context_thai_filter_keypress(), the key event is first checked if it affects caret position, by checking for special modifiers like Ctrl, Alt, Meta, or if the key moves the caret (using is_context_lost_key() function). Among these keys are keypad arrows, Home, End, PgUp, PgDn. These were unfortunately checked against GDK keysym range from GDK_KP_Space (0xff80) to GDK_KP_Equal (0xffbd), which covers numeric keypads GDK_KP_0 (0xffb0) .. GDK_KP_9 (0xffb9) and the arithmatic operators GDK_KP_Multiply (0xffaa) .. GDK_KP_Divide (0xffaf). So, these character-generating keys were evaluated like caret moving keys, which was wrong. Indeed, the upper bound of the range should be GDK_KP_Delete (0xff9f), so the wrong keys are not included. This was missed in the initial patch partially because the keysyms in <gdk/gdkkeysyms.h> were not sorted, and partially because I hadn't tested it (I've been using notebook keyboard..) until some user reported it against gtk-im-libthai after the patch had been proposed to upstream GTK+. So, this proposed patch just propagates the fix upstream.
GTK+ developers, OK if I committed the patch?
Let's close this bug. As the fix is explained and tested, I'll commit it within 12 hours, unless there is any objection.
Timed out, with no objection. Committed: 2009-02-18 Theppitak Karoonboonyanan <thep@linux.thai.net> Bug 457086 - numpad does not work when the Thai-Lao input method is used * modules/input/gtkimcontextthai.c (is_context_lost_key): Do not count character-generating keypads as context-lost keys.
As a general rule, posting ultimatums and committing without approval is never acceptable. Please revert the commit or I'll have your cvs access nuked.
No problem to revert. Sorry for the annoyance. But please note that it's not what I usually do. For this case: - I remember being assigned to maintain Thai modules in GTK+ and Pango by Owen several years ago. But I rarely execute that right til now, except for some first commits and follow-ups. After that, I usually ask for approval before committing, like in Comment #12 in this case, as well as in other bugs. (But I never committed unapproved in those bugs.) - I've already waited for almost a week. The last 12-hour wait was to ask for sure before I did something possibly rude. - I usually avoid pre-approval commits in general. But I consider this case very obvious to me, with small change in a little module, whose effect is known to be narrow, and most importantly, with long-time adoption and testing downstream. And with the right I presume, I decided to do it myself rather than bugging developers for such little change. All that said, I realize that I have broken the rules. And I'm going to revert it as requested. I'll avoid doing this again in the future.
Reverted: 2009-02-19 Theppitak Karoonboonyanan <thep@linux.thai.net> * modules/input/gtkimcontextthai.c (is_context_lost_key): Revert the unapproved patch for bug 457086.
Thanks. I'll try to get you a patch review by the end of the week.
(In reply to comment #18) > I'll try to get you a patch review by the end of the week. I hope you don't forget this patch yet. I believe it wouldn't distract you too much to review it. Thanks.
Sorry, I forgot. Patch looks harmless enough to me. I have now fixed the sorting of GDK_KP_Equal in gdkkeysyms.h.
Thanks for the review and the additional fix. Committed: 2009-03-02 Theppitak Karoonboonyanan <thep@linux.thai.net> Bug 457086 - numpad does not work when the Thai-Lao input method is used * modules/input/gtkimcontextthai.c (is_context_lost_key): Do not count character-generating keypads as context-lost keys. (patch recommitted after approval)