GNOME Bugzilla – Bug 129295
KeyMan doesn't work as expected with GTK
Last modified: 2013-08-14 02:00:32 UTC
The problem I am having occurs when using WinGaim (i.e., port of Gaim to Win32). In the input textfield when in a chat window, I am not able to use this program (Tavultesoft's Keyman -- http://www.tavultesoft.com/keyman/) which converts keyboard strokes into characters. Keyman works just fine for windows applications (it works for Win98-WinXP). It seems to work by intercepting the keystrokes that the user types and somehow dynamically updating the text that the target application (i.e., the application which has the user's focus) receives and displays. When using Keyman with WinGaim, the none of the input that comes from Keyman after the keystroke convesion reaches the textfield of WinGaim. However, if I type the same input into Notepad and copy and paste the results that appear in Notepad (the results which are correct) into WinGaim, WinGaim displays the text properly (i.e., I see what I intended to see). But instead of having to copy and paste the results from a 2nd window into WinGaim, I want to be able to use Keyman directly with WinGaim. In case it is relevant, the keystrokes that I type (and are intercepted by Keyman for conversion) are in the range 'a'-'z' and 'A'-'Z'. The output characters are in the ASCII 128-255 range. Unicode encoded text also doesn't work with WinGaim (however Unicode text doesn't work with AOL AIM either). Thanks, -- Elango
A couple of points: - What do you mean with "os-level" input mechanism? Isn't KeyMan 3rd- party software, like GTK? Does it include some driver-level software, or does it run entirely as a user process? - The ASCII range is 0-127. 128-255 are not ASCII. They are from some Windows code page. - Are you sure KeyMan works with all other applications on Windows? Especially, try checking other 3rd-party, large, multi-platform applications. I suspect they might well have similar problems with KeyMan. For instance, try Mozilla, XEmacs, GNU Emacs, Java, or Adobe's applications. - What is the actual use case? Do you need KeyMan to extend your keyboard layout only occasionally? In that case, you can enter any Unicode character to GTK using Shift+Control+code point in hex. Or do you write text all the time using characters that aren't supported by the keyboard layout you have selected in Windows? Wouldn't it in that case be more correct to just add a new keyboard layout in the Control Panel, and switch to it when necessary for WinGaim, using the indicator on the taskbar (or a hotkey)? Still, I will have a look at what KeyMan actually does, and if it is easy to change GTK to make them behave together as users expect, I'll do it.
Thanks for your questions, Tor. Here are some responses to your questions, and I hope they help: - Yes, KeyMan is 3rd party software. I think it runs as a user process (it appears in the list of processes in the "Process" tab of Windows Task Manager) - oops. sorry about saying that. - I have used it with Mozilla without problems for a long time. I just tried it with the Windows port of GIMP, and it works fine there. (I inputted the desired text using the text tool.) I just tested it out with the Java Swing-based Notepad application in the "Java Web Start" application (I'm assuming Java Web Start comes along with any JRE installation). In anycase, the Java Swing-based Notepad applicaiton seemed like it was written purely in Java, and there were no problems. It works in Adobe Acrobat (4.0) as well. - I use Keyman to write text in Tamil that corresponds to different styles of Tamil font encoding. For example, I can type the letters "paal" on my keyboard, but by switching Keyman to a Tamil TSCII "keyboard plugin", the text that Keyman renders will form the word "paal" in Thamil letters when viewed with a TSCII-friendly Tamil font. Likewise, there are "keyboard plugins" for Keyman that render Tamil text in Unicode, as well as other Tamil font styles (TAM, TAB, etc.) With the exception of Unicode output, all output under the other font encodings falls in the 0-255 range for characters. (Yes, there is no need for so many Tamil font encodings. That is just the way it is, unfortunately.) To give you an example of what Keyman does when using the TSCII "keyboard plugin", below are 3 cases of input followed by the output rendered by Keyman: "k" ì "ko" ¦¸¡ "koo" §¸¡ This change is correct because Tamil has what Windows loosely defines as a complex/non-linear script. The beauty is that the English input is phonetical, and the output is *magically* correct. Thanks for your help. -- Elango
Only Unicode input could conceivably work with GTK+. GTK+ uses Pango to take Unicode text, including for scripts like Tamil and rendering them correctly. On Windows, this is implemented via Uniscribe. On Linux/Unix, via built-in code. (Or, with some work that is being done now, via SIL graphite.) If you feed GTK+ pre-shaped pseudo-text, it's not going to work at all.
*** Bug 142510 has been marked as a duplicate of this bug. ***
I think Keyman generates Unicode. It is far more useful than switching keyboards, because it allows a finite-state machine to convert several keystrokes into one character, or one keystroke into several characters, all conditional on the local context. For Yiddish, it is far easier (and more complete) than using the Hebrew keyboard, for example, which lacks some of the characters. The alternative is to write a Tamil or yiddish or whatever input method for GTK+. I have a Yiddish input method that works fine under Unix.
It would be nice if somebody would try KeyMan with current GTK+ (2.6.7).