Re: XIM, kinput2 & Tk

[jwb@example.com (Jim Breen)]

>> From: "Stephen J. Turnbull" <turnbull@example.com>

>>   Tk has no idea how it is done.  The XIM model is that
>> Kinput2 makes all the decisions about what to do with keystrokes,
>> including the initiation sequence.  TheRe's no reason why Kinput2,
>> xwnmo, et al need to use the same sequence, and (this being Eunuchs)
>> they probably don't.  And of course the user or sysadmin can configure
>> it to something else again.

I can't argue against this (as I simply don't know), but
kinput2 must be a bit different when there it is running in native mode
as opposed to XIM mode.

I do most of my kinput2 usage from within a kterm. If I don't have
kinput2 running, kterm works quite happily, however if I press the 
kinput2 initiation sequence, it starts squawking about there being no
conversion process. The sequence is defined in my .Xresources:

	kterm*VT100*Translations: #override \
		Shift<Key>space: begin-conversion(_JAPANESE_CONVERSION)

From this I conclude that the initiation sequence is detected by kterm,
and it whistles up kinput2.

It's similar in Yudit, although the sequence is in a function key. Again
this is in Yudit's control file.

Now working from what Stephen wrote above, kinput2 or whatever must be
active and grabbing all keystrokes to trap any initiation sequences, etc.
before passing them to whichever app they are intended for.

How the hell does it do that? The kinput2 man page says: "kinput2 waits
quietly for a Japanese text input request from another client (i.e. no
windows  appear).   When  kinput2 receives a request, it pops up a
window and starts conversion process." No mention whatsoever that
traps the sequence itself.

>> I believe the delegation of control of the keyboard to the IM is also
>> true for Mac and Windows, but presumably The Kanji Key wins there
>> "Because Bill-sama Says So."

Actually divorcing the IM from the app is Good Thing, but in the case
of Windblows, the app has the speak the IM's API for it to work (unless
it's something like NJComm, in which case it just monkeys with
keystrokes on the fly and the app is unaware.)

>>     >>> and (b) LANG="ja_JP.eucJP" (probably, works for me but YYMV)
>>     >>> in your environment or you will lose.  Of course, you may lose
>>     >>> anyway; this is XIM.
>> 
>>     Jim> Doesn't work. Possibly because LC_ALL contains "C", according
>>     Jim> to the return from setlocale().
>> 
>> OK, well you can try invoking your "tkApp" (more forcibly) with
>> "LC_ALL=ja_JP.eucJP tkApp".

Hmph. I'm running Tk from within a C wrapper system (mktclapp). I've
tried running it from a shell with LC_ALL set as you suggest, and it
makes no difference.

Jim
-- 
Jim Breen  [jwb@example.com  http://www.csse.monash.edu.au/~jwb/]
Visiting Professor, Institute for the Study of Languages and Cultures of 
Asia and Africa, Tokyo University of Foreign Studies, Japan
+81 3 5974 3880         [$B%8%`!&%V%j!<%s(B@$BEl5~30Bg(B]