Tk Source Code

To date, developers here have been unable to get tcl/tk
8 to interact with the japenese kanji input method
application kinput2 while using SPARC Solaris 8.

However, one of our developers spent some time and
worked out the changes necessary to get this to work.

Here is what the developer reported back to me,
regarding the slight change needed so that things work
right on Solaris:

./tk8.4.5/generic/tkEvent.c
880a881
>           long im_event_mask;
933a935,938
>           XGetICValues(winPtr->inputContext,
XNFilterEvents, &im_event_mask, N
ULL);
>           winPtr->atts.event_mask |= im_event_mask;
>           XSelectInput(winPtr->display,
winPtr->window, winPtr->atts.event_mas
k);
>           XSetICFocus(winPtr->inputContext);

The contractor went on to say:

   Basically, the window wasn't requesting input method
events before trying to  filter them with XFilterEvent.
 There is nothing in the code I added that is Solaris
specific.  I don't know why Japanese input behaves
differently than on other Unix versions.

Logged In: YES 
user_id=68433

> status?

Fixed in CVS HEAD and in core-8-4-branch; verified on
Debian, SuSE, and Solaris.

The "more comprehensive patch" mentioned earlier
(2005-12-15) isn't finished yet -- there's still quite a bit
of stuff that should be cleaned up -- but the immediate
problem with SCIM has been fixed.  

Closing the bug for now, can apply cleanups later.

Logged In: YES 
user_id=80530

status?

Logged In: YES 
user_id=15949

While part of the patch file, itself, was incompatible 
wtih 8.4.12 here on Solaris (the patch appears, from what 
I could tell, to be against 8.5 code), I manually inserted 
the code into 8.4.12, and had Neil Ostrove test and he 
reports back that the change appears to work on SPARC 
Solaris.

Logged In: YES 
user_id=68433

rmax reported on the chat a while ago that the patch works
for Suse.  No feedback yet from Solaris users.

Committing to core-8-4 branch and CVS HEAD for wider testing.

File Added - 159999: tk84-xim-fixes.patch

Logged In: YES 
user_id=68433

Attached patch against Tk 8.4.12 is a minimal change that
seems to fix SCIM.  Tested on Debian "sarge" with:

    LC_CTYPE=ja_JP.UTF-8 XMODIFIERS=@im=kinput2
    LC_CTYPE=en_US.UTF-8 XMODIFIERS=@im=SCIM
    LC_CTYPE=zh_CN.UTF-8 XMODIFIERS=@im=SCIM

Summary of changes:

+ Revert change disabling @im=SCIM from 2005-12-05.
+ Make sure all X events get passed to XFilterEvent(), not
just those with a corresponding Tk window.

Please test.  A more comprehensive patch to Tk CVS HEAD to
follow.

Logged In: YES 
user_id=68433

Probable cause of the SCIM breakage: XFilterEvent() is only
being called for X events directed to a Tk window (call
chain: Tk_HandleEvent -> InvokeInputMethods -> XFilterEvent;
but Tk_HandleEvent bails out early if GetTkWindowFromXEvent
returns NULL).

It looks like SCIM is using ClientMessages to a private
(SCIM-generated) X window for part of the communication. 
Since those never get passed to XFilterEvent, the IM window
never gets activated.

Calling XFilterEvents() earlier on, however, causes a
different sort of breakage -- input methods only work if the
mouse is directly over the focus widget.  (There are a lot
of other focus-related glitches too).

I think I've finally got a handle on this, though, patch to
follow.

File Added - 158729: tk-scim-workaround.patch

Logged In: YES 
user_id=124643

I am attaching the patch mentioned in
https://bugzilla.novell.com/show_bug.cgi?id=77424#c24 and
also just applied it to HEAD.

Whether it gets applied to 8.4 before or after 8.4.12, or
not at all is now up to the Tk maintainers.

Logged In: YES 
user_id=72656

Note also 910127 1204469 and

https://bugzilla.novell.com/attachment.cgi?id=48662

And this is the respective bug report: 
https://bugzilla.novell.com/show_bug.cgi?id=77424

Logged In: YES 
user_id=80530


Any hope for a backport
into Tk 8.4.12 ?

Logged In: YES 
user_id=72656

This is a discussion about a patch for fixing SCIM, which is
related:

<rmax> The patch is attached to the SUSE bug report:
https://bugzilla.novell.com/show_bug.cgi?id=77424
<rmax> When using Compose, and the first thing ever typed in
an entry widgets is the Compose key, it ignores Compose for
this first composed character.
<rmax> The same happens sometimes when the mouse pointer
gets moved out of the entry, or (more frequently) when it
gets moved out of the respective toplevel window.
<tclguy> what focus style do you use?
<rmax> In fvwm2 I use focus follows mouse, and sloppy focus.
<rmax> that means, that the focus isn't taken away from a
window when I move the mouse out to the root window.
<tclguy> right, until you reach another toplevel
<rmax> But a colleague who uses click to focus has seen
similar problems.
<rmax> What I've found out about it so far is, that the
first keypress ever is reported to the toplevel windows,
although the entry was explicitly given [focus].
<rmax> That doesn't seem to be a problem unless that very
first keypress is Compose.
<rmax> The patch tries to do some tricks with the mouse
position. When I remove them, the situation with mouse moved
out of widget gets better, but sometimes it still happens.
<tclguy> OK, I may get to it today, but I have to slog
through my email first
<rmax> ... and the problem with the first keypress is almost
always there.

Logged In: YES 
user_id=124643

It was still missing on HEAD. Done now.

Logged In: YES 
user_id=72656

rmax - reminder?  I think this is all done, but bug is still
open.

Logged In: YES 
user_id=15949

Jeff, the code that rmax submitted was done against tk
8.4.7, so I don't know what 'backported to 8.4' means.

Logged In: YES 
user_id=72656

This never got backported to 8.4.

Logged In: YES 
user_id=15949

Re: is this one finished.

With Reinhard's changes, it appears that things work on
SPARC Solaris and Reinhard appeared to be satisfied.

Logged In: YES 
user_id=72656

Is this one finished?

Logged In: YES 
user_id=124643

That the Compose key doesn't work after these environmental
changes is not a bug. There can only be one input method
active at a time, and that is either kinput2 or Compose.

Logged In: YES 
user_id=15949


Here's two notes relating to this bug.

1. To get Tk to interact with the japanese x input methods
AFTER the patch we include in this bug report, we had to
make these environmental variable changes (and then exported
the variables):

a. LANG="ja"
b. XMODIFIERS="@im=kinput2"
c. unset LC_ALL LC_CTYPE

then make certain that XUSERFILESEARCHPATH includes the
directory containing the kinput2 application resource file.

Then we had to start kinput2:
kinput2 -xim -kinput -canna -cannaserver ourserver &

Then, to test within Tk, we used:
pack [entry .a];
entry .b
entry .c
pack .c .b;
pack [frame .f];

and used the <shift>Space key to activate the kinput2 over
the spot conversion.

2. With the above environmental changes, regardless of
whether we used a wish patched with this patch (or rmax's
patch, etc.), the Compose key does not work.  Without the
above environmental changes, the Compose key works just
fine, on all 3 entry widgets,  on SPARC Solaris 8 (using
GNOME , if that is at all relevant).

File Added - 95705: XSetICFocus-8.4.7.patch

Logged In: YES 
user_id=124643

It seems the code block that calls XSetICFocus got inserted
at the wrong place. It only gets called when a window gets
mapped for the first time, but it should get called on evert
FocusIn event, so that the input focus for XIM gets moved to
the right window. The new patch should fix this.

Larry, would you please check if things still work on
Solaris with the new patch applied?

Logged In: YES 
user_id=80530


This patch has apparently introduced
a new bug (1000051) in Tk 8.4.7

Logged In: YES 
user_id=72656

I had to check that inputContext was not NULL, but otherwise
this looks OK on Linux (don't have Solaris with JP patches
for testing).  Added it to 8.4.7 and 8.5-head.

Logged In: YES 
user_id=15949

I don't know why, but for some reason, the fact that an
updated patch was attached to this message, I thought with a
comment, doesn't seem to have included the comment here.

File Added - 86029: XIM.patch

Logged In: YES 
user_id=72656

This patch isn't helpful without context.  Please attach
patch made with diff -u, as the core-8-4-branch head is
different (patch below will not apply).

Logged In: YES 
user_id=15949

the patches have been confirmed to work successfully with
sparc solaris 8 and tk 8.4.6 - this patch MUST be installed
for XIM to work on sparc solaris.

Logged In: YES 
user_id=15949

Actually, the 'change' to the LC_CTYPE and LC_ALL variables
that is being suggested is just to unset them.

Logged In: YES 
user_id=15949

Turns out that one final resolution to the GNOME issue has
turned up.
The local setup for GNOME included setting LC_CTYPE and
LC_ALL to
C before the user ever logged in.  This caused problems with
input method support.  Changing the LC_ values, along with
the Tk patch in this report,
resulted in the sparc solaris environment being able to use
the tk input method support.

Logged In: YES 
user_id=15949

Turns out that with a slight change to the original patch,
things look much better for Tk with regards to the X error
that was mentioned.  However, there is still one gotcha -
unrelated to Tk:

First, the new Tk patch:


./tk8.4.5/generic/tkEvent.c
880a881
>           long im_event_mask = 0L;
932a934,941
>           }
>           XGetICValues(winPtr->inputContext,
>               XNFilterEvents, &im_event_mask, NULL);
>           if (im_event_mask != 0L) {
>               XSelectInput(winPtr->display, winPtr->window,
>                   winPtr->atts.event_mask | im_event_mask);
>               XSetICFocus(winPtr->inputContext);



Now, the gotcha - even with this patch, on Sparc Solaris's
shipped GNOME distribution, things don't work right out of
the box.  Instead, we have found that if we rlogin to the
machine from a running GNOME session, then set the DISPLAY
variable to "machine:0.0" , then start kinput2 and the
application, things work fine.

This is NOT Tk related - we are seeing similar weird things
with non-Tk apps that interact with this kinput2 (version
2.0 fix 2).

Things work fine under CDE and OpenWindows AFTER this patch
is applied - before this patch, we were unable to get tk
apps to interact with kinput2.

Logged In: YES 
user_id=15949

The developer reports one bug encountered after this patch:

If you tell wish to expect a kinput2 input server with

LC_CTYPE=ja XMODIFIERS="@im=kinput2" wish

and kinput2 isn't running, then an X error is generated

  X Error of failed request:  BadValue (integer parameter
out of range for operation)
  Major opcode of failed request:  2 (X_ChangeWindowAttributes)
  Value in failed request:  0xffef9a7f
  Serial number of failed request:  214
  Current serial number in output stream:  412



----
He is working on a fix for this now.