Menu
▾
▴
#2186 XIM does not work with ATOK12 on Solaris8
open
8
2010-01-02
2006-12-26
No
I use ATOK12 on Solaris for converting Japanese character.But it does not work
on tcl/tk 8.4.4 and 8.4.13.
When I convert Japanese character to KANJI on a text area, input server(ATOK12)
makes an auxiliary area(an auxiliary window) for selecting from some KANJI. But
nothing can be input on the text area after selecting a KANJI .
When ATOK12 makes an auxiliary-window, tck/tk receives a FocusOut event.
After selecting a KANJI on the auxiliary-window, tck/tk receives A KeyPress
event with a KeyCode of zero and then receives a FocusIn event.
In this case I thought event order should be a FocusOut event, a FocusIn event and then
a KeyPress event according to Xlib specifications. So I asked Sun Microsystems
which order is correct.
(A) a FocusOut event -> a FocusIn event -> KeyPress event with a KeyCode of zero
(B) a FocusOut event -> a KeyPress event with a KeyCode of zero -> FocusIn event
Their answer was "Both are OK.". This means Tcl/tk could have same problem not only
ATOK12 but also other input servers.
Discussion
Logged In: YES
user_id=1676667
Originator: YES
Please let me know the state of this problem.
Is there any idea about the solution of this problem?
Logged In: YES
user_id=79902
Originator: NO
Does it work with 8.4.14? Or 8.5a5?
I ask because historically the way Tk processed events was different from the way that Input Managers tended to expect. This in turn was due to the fact that the XIM protocol is horribly under-specified (too much "just use *this* library" without explanation of what is going on) and none of the core Tk developers actually use complex input methods in their normal day-to-day work. This has made understanding what the problem is and testing solutions difficult. *Maybe* the latest releases get it right, but maybe not. There are certainly still bugs in this area, but I can't tell from your report whether you're hitting one of them (are you using the [bind] command yourself? If so, there's a known problem - Bug#1373712 - with non-repeatability of the %A substitution. But if you're not using it, the problem is elsewhere.)
Assigning to jenglish because he knows a bit more about input method support than I do (and is more likely to have time than hobbs).
Logged In: YES
user_id=1676667
Originator: YES
The same problem occurs on 8.4.14 and 8.5a5.
This case is not same as Bug#1373712 and it does not use the [bind] command.
There is a case that Tcl/Tk in a FocusOut state receives A KeyPress event
with a KeyCode of zero.
In this case Tcl/Tk does not execute process about the KeyPress event,
because "winPtr==NULL" as follows.
tk8.4.14/generic/tkEvent.c
848 winPtr = TkFocusKeyEvent(winPtr, eventPtr);
849 if (winPtr == NULL) {
850 Tcl_Release((ClientData) interp);
851 return;
852 }
Logged In: YES
user_id=1676667
Originator: YES
I reported as follows.
>The same problem occurs on 8.4.14 and 8.5a5.
Afterward I confirmed the same problem occurs on 8.5a6,also.
Is there any solution?
Recent changes by dkf have most likely fixed this problem as well. Is it possible to retest with CVS HEAD?
Or the tip of the Tk 8.5 branch. That's got the same changes.
The changes have not fixed Bug#1622189.
It tested with both CVS HEAD and core-8-5-branch.
Right now, we're feeding the raw X11 event stream into the XIM handler. The one thing that's not correct is the timing of the configuration of XIM in response to focus events, but it's not clear to me how to do that; focus handling needs to go through the main Tcl/Tk event queue because it is scripted.