[ tktoolkit-Bugs-905830 ] Fix needed for Solaris & SCIM IME support

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[ tktoolkit-Bugs-905830 ] Fix needed for Solaris & SCIM IME support

SourceForge.net
Bugs item #905830, was opened at 2004-02-27 04:58
Message generated for change (Settings changed) made by hobbs
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=905830&group_id=12997

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 69. Events
>Group: current: 8.4.11
>Status: Open
>Resolution: Remind
>Priority: 8
Submitted By: Larry W. Virden (lvirden)
Assigned to: Reinhard Max (rmax)
>Summary: Fix needed for Solaris & SCIM IME support

Initial Comment:
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.


----------------------------------------------------------------------

>Comment By: Jeffrey Hobbs (hobbs)
Date: 2005-09-05 12:34

Message:
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.


----------------------------------------------------------------------

Comment By: Reinhard Max (rmax)
Date: 2004-11-11 03:34

Message:
Logged In: YES
user_id=124643

It was still missing on HEAD. Done now.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2004-11-10 14:00

Message:
Logged In: YES
user_id=72656

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

----------------------------------------------------------------------

Comment By: Larry W. Virden (lvirden)
Date: 2004-09-24 10:42

Message:
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.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2004-09-24 10:32

Message:
Logged In: YES
user_id=72656

This never got backported to 8.4.

----------------------------------------------------------------------

Comment By: Larry W. Virden (lvirden)
Date: 2004-09-10 04:57

Message:
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.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2004-09-09 23:42

Message:
Logged In: YES
user_id=72656

Is this one finished?

----------------------------------------------------------------------

Comment By: Reinhard Max (rmax)
Date: 2004-07-30 11:36

Message:
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.

----------------------------------------------------------------------

Comment By: Larry W. Virden (lvirden)
Date: 2004-07-30 06:29

Message:
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).



----------------------------------------------------------------------

Comment By: Reinhard Max (rmax)
Date: 2004-07-29 11:03

Message:
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?

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2004-07-29 09:44

Message:
Logged In: YES
user_id=80530


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

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2004-07-20 20:05

Message:
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.

----------------------------------------------------------------------

Comment By: Larry W. Virden (lvirden)
Date: 2004-07-20 05:18

Message:
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.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2004-05-03 17:24

Message:
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).

----------------------------------------------------------------------

Comment By: Larry W. Virden (lvirden)
Date: 2004-04-21 08:48

Message:
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.

----------------------------------------------------------------------

Comment By: Larry W. Virden (lvirden)
Date: 2004-03-10 03:18

Message:
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.

----------------------------------------------------------------------

Comment By: Larry W. Virden (lvirden)
Date: 2004-03-10 03:11

Message:
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.

----------------------------------------------------------------------

Comment By: Larry W. Virden (lvirden)
Date: 2004-03-08 12:11

Message:
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.



----------------------------------------------------------------------

Comment By: Larry W. Virden (lvirden)
Date: 2004-03-05 09:19

Message:
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.



----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=905830&group_id=12997


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Tcl-Bugs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-bugs