Fix needed for Solaris & SCIM IME support

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.

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

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

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

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=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).

context diff of fix to tk 8.4.6 tkEvent.c for SPARC Solaris XIM support.

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.

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=80530

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

diff for 8.4.7 to fix the Compose key

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=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).

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=72656

Is this one finished?

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

This never got backported to 8.4.

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.