#2186 XIM does not work with ATOK12 on Solaris8

obsolete: 8.4.4

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.


  • Donal K. Fellows

    • priority: 5 --> 8
    • assigned_to: nobody --> hobbs
  • kouritsu

    kouritsu - 2007-04-06

    Logged In: YES
    Originator: YES

    Please let me know the state of this problem.
    Is there any idea about the solution of this problem?

  • Donal K. Fellows

    Logged In: YES
    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).

  • Donal K. Fellows

    • assigned_to: hobbs --> jenglish
  • kouritsu

    kouritsu - 2007-04-11

    Logged In: YES
    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.


    848 winPtr = TkFocusKeyEvent(winPtr, eventPtr);
    849 if (winPtr == NULL) {
    850 Tcl_Release((ClientData) interp);
    851 return;
    852 }

  • kouritsu

    kouritsu - 2007-05-02

    Logged In: YES
    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?

  • Joe English

    Joe English - 2010-01-02

    Recent changes by dkf have most likely fixed this problem as well. Is it possible to retest with CVS HEAD?

  • Donal K. Fellows

    Or the tip of the Tk 8.5 branch. That's got the same changes.

  • Donal K. Fellows

    • labels: 104343 --> 67. Unix Window Operations
  • kouritsu

    kouritsu - 2010-01-13

    The changes have not fixed Bug#1622189.
    It tested with both CVS HEAD and core-8-5-branch.

  • Donal K. Fellows

    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.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks