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 457086 - numpad does not work when the Thai-Lao input method is used
numpad does not work when the Thai-Lao input method is used
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Input Methods
2.10.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2007-07-15 10:57 UTC by upatan
Modified: 2009-03-02 18:35 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Don't count character-generating KPs as context-lost keys (723 bytes, patch)
2009-02-10 04:50 UTC, Theppitak Karoonboonyanan
committed Details | Review

Description upatan 2007-07-15 10:57:28 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
Comment 1 Raphaël Quinet 2007-07-15 22:04:17 UTC
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.
Comment 2 upatan 2007-07-16 02:09:03 UTC
- 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 
Comment 3 Sven Neumann 2007-07-16 10:14:39 UTC
What operating system are you using? Which version of GTK+ ?
Comment 4 upatan 2007-07-16 10:26:21 UTC
(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
Comment 5 Tor Lillqvist 2007-07-23 22:40:22 UTC
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?
Comment 6 Theppitak Karoonboonyanan 2007-08-25 01:51:57 UTC
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.
Comment 7 Tobias Mueller 2009-02-09 23:06:10 UTC
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...)
Comment 8 Theppitak Karoonboonyanan 2009-02-10 04:50:10 UTC
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.
Comment 9 Tobias Mueller 2009-02-10 23:41:29 UTC
Yay a patch :) While it looks simple, I don't understand it ;-) But maybe does Tor :) *poke*
Comment 10 Tor Lillqvist 2009-02-11 00:28:25 UTC
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".
Comment 11 Theppitak Karoonboonyanan 2009-02-13 08:31:47 UTC
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.
Comment 12 Theppitak Karoonboonyanan 2009-02-14 02:20:43 UTC
GTK+ developers, OK if I committed the patch?
Comment 13 Theppitak Karoonboonyanan 2009-02-18 03:12:33 UTC
Let's close this bug. As the fix is explained and tested, I'll commit it within 12 hours, unless there is any objection.
Comment 14 Theppitak Karoonboonyanan 2009-02-18 15:19:39 UTC
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.
Comment 15 Matthias Clasen 2009-02-18 18:56:00 UTC
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.
Comment 16 Theppitak Karoonboonyanan 2009-02-19 02:02:10 UTC
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.
Comment 17 Theppitak Karoonboonyanan 2009-02-19 02:05:19 UTC
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.
Comment 18 Matthias Clasen 2009-02-19 02:22:19 UTC
Thanks.

I'll try to get you a patch review by the end of the week.
Comment 19 Theppitak Karoonboonyanan 2009-03-02 02:35:59 UTC
(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.
Comment 20 Matthias Clasen 2009-03-02 03:12:37 UTC
Sorry, I forgot. Patch looks harmless enough to me. 
I have now fixed the sorting of GDK_KP_Equal in gdkkeysyms.h.
Comment 21 Theppitak Karoonboonyanan 2009-03-02 04:17:58 UTC
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)