GNOME Bugzilla – Bug 81031
immodules for Thai
Last modified: 2006-11-29 19:48:11 UTC
I just tested gtk+ 2.0.2 and I found that there is a module ,imthai-broken.c, working with Thai input. However, I found in the source that this module works for converting Thai TIS620 charset to Unicode, such as from 0xa1 to 0x0e01, which is not useful since I have to set xkb to Thai in X before I can type Thai and when I set xkb, this module will not necessary. I think this module had better work for converting qwerty key to Unicode (in thai) such as 0x64 to 0x0e01. I try to create compose_seqs due to TIS820-2538 which is This Industrial Standard for Keyboard. Then, I change the module name to imthai-tis820.c
Created attachment 8250 [details] immodule for Thai keyboard (TIS820-2538)
I think that a non-broken Thai input method should just expect a Thai keyboard map and handle prohibiting or correcting mis-ordered input sequences. See, the thread from: http://mail.gnome.org/archives/gtk-i18n-list/2001-October/msg00043.html Much work needs to be done on making switching input methods and keymaps convenient for users on the Unix desktop, but I don't think using input methods to substitute for keymaps helps with that.
Putting on 'future' as a wishlist item, since I don't think a Thai-specific input module is needed for correct operation.
I have tried hacking out the imthai module, as in the patch attached. Note that my patch in bug #101814 (attachment #13303 [details]) also enable GTK+ to use Thai XIM through the StringConversionCallback. And I hope this imthai patch will enable elegant Thai input method in non-XFree86 environments also.
Created attachment 13555 [details] [review] imthai patch
I find some bug in fallbacks when the signals are not handled. So, I have polished the patch a little more.
Created attachment 14691 [details] [review] polished patch (against gtk+ 2.2.1)
Comment on attachment 13555 [details] [review] imthai patch This patch is obsoleted by the newer one.
Created attachment 33345 [details] [review] Updated patch, against CVS HEAD 2004-11-02 snapshot, with Lao support. In parallel to Lao support in Pango proposed in Bug #156781, I create another patch using the enhanced tables extracted from the Pango patch. This makes the IM support both Lao and Thai in the same module.
Added Anousak Souphavanh from Laonux project to Cc: list.
Should this bug be targeted to 2.6.0, in parallel to Bug #156781 for Lao support in Pango?
Matthias, can I commit this to HEAD and stable and remove thai-im-broken? I committed thai-lang module to Pango, so Pango now fully supports Thai without any external module.
I haven't looked at the patch, but I have no objections to replacing imthai-broken by something better. No need to let this work languish in bugzilla another 2 years...
Ok, landing this on HEAD. May I commit to branch too, so it gets in a stable release soonish?
Created attachment 77319 [details] [review] committed patch Committed to HEAD: 2006-11-28 Behdad Esfahbod <behdad@gnome.org> Remove the broken Thai input method and add a functional Thai and Lao input method by Theppitak Karoonboonyanan. (#81031) * modules/input/imthai.c: * modules/input/gtkimcontextthai.c: * modules/input/gtkimcontextthai.h: * modules/input/thai-charprop.c: * modules/input/thai-charprop.h: Added. * modules/input/imthai-broken.c: Removed. * modules/input/Makefile.am: Updated.
Leaving open to get mclasen's ack and commit to branch.
Thep, can you test Pango HEAD and Gtk+ HEAD and confirm that shaping, line breaking, and input method are all working as expected now?
(In reply to comment #17) > Thep, can you test Pango HEAD and Gtk+ HEAD and confirm that shaping, line > breaking, and input method are all working as expected now? For the record, I've tested Pango HEAD and it all works well. And I'll manage to build GTK+ HEAD for testing soon. (Currently, I'm using gtk-2-10 branch as per jhbuild's gnome-2.18 moduleset.)
Before testing GTK+ HEAD, I've applied your updated patch to gtk-2-10 branch, for quick test. It works for both Lao and Thai.
GTK+ HEAD is also tested. The Thai-Lao input method works here as well.
No objection from me for putting it in the stable branch then
Committed to gtk-2-10 too.