Tk Source Code

Dear Team,

The odoubleacute and udoubleacute symbols cannot be 
inserted into, say, a text or an entry. These symbols 
can be generated with any standard distribution using 
"setxkbmap hu", by pressing '[' or '\'.

Here is a testprogram:

wish8.4 [~]entry .e
.e
wish8.4 [~]pack .e
wish8.4 [~]bind .e <Key> {puts "%K, %A, %N"}

After pressing these keys, the output is:

odoubleacute, {}, 501
udoubleacute, {}, 507
Shift_L, {}, 65505
Odoubleacute, {}, 469
Udoubleacute, {}, 475

I tested it with a Mandrake 9.2 install, and with a 
cygwin XFree86 server.

Is it the problem of tk, or the problem of X?

(There are other hungarian keyboard layouts, which use 
latin2-encoding instead of unicode, and there these two 
keys generate otilde and uumlaut keysyms, which are 
happily accepted by tk, but not, for example, by 
StarOffice. :((  )

Logged In: YES 
user_id=72656

Dup of 905830

Logged In: YES 
user_id=72656

See also 1204469

Logged In: YES 
user_id=970622

I just discovered that doing an

export LANG=tr_TR

and then running the applications from there solves the
problem. This shouldn't be necessary, however. I don't want
to change the LANG setting in /etc/profile since it may
cause problems in other applications. I hope there's an easy
fix for this.

Logged In: YES 
user_id=970622

I'm sorry, since I'm not a Tcl/Tk programmer I'm not sure
about how to check that. I looked at Tk documentation and
tried the following: I found the piece of code that creates
a chatwindow in aMSN. After the line

set w [CreateTopLevelWindow]

I added the lines

tk useinputmethods -displayof $w true
if {[tk useinputmethods -displayof $w]} {puts "XIM on"}

Now, when I open a chatwindow I get the "XIM on" message at
the console. But the problem persists.

If you think that what I did is wrong, please write your
suggestions and I'll forward them to the aMSN developers so
that they can try. They've already taken a look at this
indeed, and believe that it's a tcl issue.

PS: XIM documentation says XIM is useful for languages such
as Japanese, Korean. I don't think that Turkish (or
Slovenian) needs that, since these two languages use the
common latin letters, and a few additional ones, e.g. a
dotless i in Turkish. -- but again, this is a comment by
someone who doesn't know about Tk :).

Logged In: YES 
user_id=79902

Sounds very much like an Input Method nasty. Have you got
input methods turned on?

Logged In: YES 
user_id=970622

I think my problem with the Turkish characters are exactly
the same. I had a problem about this on aMSN and it is
decided that it is a Tcl/Tk issue. Later there was a similar
report about Slovenian characters having the same problem.

Here's the link to the aMSN bug report page. I'm copying my
first message which describes the bug:

http://sourceforge.net/tracker/index.php?func=detail&aid=1084913&group_id=54091&atid=472655

 The encoding for Turkish is iso-8859-9. I choose
Turkish as the language, and iso-8859-9 as the
encoding. All menu entries, button labels etc. print
correctly. All Turkish letters in the messages coming
from my contacts also print correctly. But I can't type
in certain Turkish letters. When I press those keys on
the keyboard, nothing happens, as if there's no input.

I had this problem with Tcl/Tk 8.4.5 and 8.4.9, amsn
0.83 +.

I remember being able to type these letters more than a
year ago, on another distro (can't remember which). At
first I thought this could be related to Slackware
10.0, which I use. But I can type these letters in
other X applications, and I was told that the same
problem occurs on Mandrake (10.x).

If you want to see yourself: Select iso8859-9, set your
keyboard map to Turkish (trq), and the keys that would
produce [, i, and ; on an English keyboard fail to work.

PS: I was also informed about a notice to Turkish
Python users, about Tcl 8.3 breaking Turkish characters
in Python 2.x. I checked the python bug tracker and
found 2 entries which *could* be relevant, but they
appear to be fixed, so I'm ruling them out for the moment.

I should also add:
I can copy/paste words including these problematic
characters into the textbox. All letters print as they
should, and the sent message also displays correctly! Only
keyboard input fails. Odd...

Logged In: YES 
user_id=72656

Was this already solved?