Menu
▾
▴
#2431 Accented characters appearing at the end of the line
closed-fixed
8
2010-01-03
2008-03-24
No
Whenever a Tcl/Tk program that has a text widget in it freezes, all input characters that have been typed with a dead key appear at the end of the line upon unfreezing of the program, regardless of where they were actually typed. Furthermore, all the characters that appear are equal to the last accented character typed.
For example (assuming the acute and grave accents require dead keys for input): typing "déjà-vu" while the program is frozen, would result in "dj-vuàà" appearing upon unfreezing.
I have reported this bug again since it appears that the previous bug cannot be updated.
Logged In: YES
user_id=68433
Originator: NO
Is this the same as #1505182? Does the problem persist under Tk 8.5.2?
I have not been able to replicate the problem. Could you provide more details about what IM manager you are using (SCIM, UIM, etc) and what the IM settings are? What OS/distro/version?
Logged In: YES
user_id=1856163
Originator: YES
Yes it is the same. It does persist under Tk 8.5.2.
I'm using Ubuntu GNU/Linux 8.04, and I think I'm using UIM, but I'm not sure. How can I determine the input method and its settings?
Logged In: NO
After removing every trace of UIM left on my system (I think I'm using SCIM now), the problem is still there. Apparently it's not an UIM problem.
Just tested in the CVS version (info patchlevel gives 8.6a3), and the bug is still there.
Still can't replicate.
Sorry, I don't know how to proceed tracking this down.
To replicate, run the following script on a wish shell (under Ubuntu, Fedora, or any other distro on which the bug has been observed):
destroy .t
pack [text .t]
after 5000 {
for { set i 0 } { $i < 100000 } { incr i } { puts test }
}
When the program freezes, start trying to input the accented characters using dead keys.
> To replicate, run the following script [...]
I have; I just don't observe the reported behavior.
This may be because I have a US keyboard with no "dead keys"; to type accented characters I have to add a Compose key with `xmodmap -e 'keysym Super_L = Multi_key Super_L' ` and then use e.g., [Windows-Key] a ' to get á.
Of course it is. The problem is triggered by DEAD keys, not compose keys.
Apparently something in your configuration is preventing the bug from being triggered in your system. Try the following, which has worked 100% of the times I've tried it:
1- Get an Ubuntu 8.04 or 8.10 liveCD for 32-bits processors.
2- While booting, choose a keyboard layout with dead keys, e.g. US-International if available, or Spanish.
3- Either download/compile the sources for Tcl/Tk (CVS version or current stable), or install them via apt.
4- run the following script on a wish shell:
destroy .t
pack [text .t]
after 5000 {
for { set i 0 } { $i < 100000 } { incr i } { puts test }
}
5- While the program is frozen, not before and not after, type a string with accenter characters, such as "déjà-vu", USING THE DEAD KEYS. Using a compose key might work in that scenario, but I haven't tried it so I don't know for sure - dead keys are the only sure way to trigger the bug.
6- Wait for the program to unfreeze. You'll see that the string which finally appears on the text widget is different from the one typed ("dj-vuàà", in the aforementioned example). You will have replicated this bug.
Using KUbuntu Jaunty. Without SCIM/UIM, it only happens with accented characters, as stated. It persists in 8.5.6, shall I test 8.6 as well? Someone mentioned that it does persist.
I believe that you will reproduce the problem if you use US-international as your keyboard layout.
You also can install either scim or uim. As soon as the xim bridge starts running, ALL characters get delayed and appear at a semi-random order, making it impossible to type.
Using aMSN with a webcam chat is almost sure to reproduce the problem as well.
Yes, I have reproduced the problem with a US-international keyboard layout.
However, I haven't so far had any problem with plain ASCII characters, neither on SCIM nor on UIM. Are you using a Greek or US keyboard layout?
Sometimes, when the CPU usage is at 100% for some time, on aMSN, the accented characters simply do not appear, or perhaps they appear on some other text widget which was selected *after* I typed the whole text.
Happy New Year :)
I made some progress here: in tkUnixKey.c , in TkpGetString , i changed the #ifdef TK_USE_INPUT_METHODS to #ifdef TK_USE_INPUT_METHODS_DELME and plain ascii letters appeared correctly. Of course, this only hits my XIM-causing-keyboard-lag issue and not the accented characters issue.
I think it's something about the variable return time of TkpGetString (or TkpGetChar). However, trying to search more, I got lost in the code. Any help would be highly appreciated. ☺
I suspect an odd interaction between the event stream that X{mb,utf8}LookupString wants and the events that Tk delivers to it. Or maybe incorrect processing of the status value returned.
Patch vs. HEAD
Can someone try the attached patch? It moves all XFilterEvent processing to the correct location while still handling focus redirection.
Which version is that patch for?
Patch WORKS :)
@fibonacci: It's against current tcl/tk cvs head.
The patch doesn't fully fix this problem.
The accented characters appear now in the right place, but all are still equal to the last one typed.
So for example "déjà-vu" appears as "dàjà-vu", and "úíúíúíúíúíúíúíúí" appears as "íííííííííííííííí".
Applied to HEAD and tip of 8.5 branch.
What it does is move the XFilterEvent call to where it should always have been. (This also fixes a few other issues.) This increases the sanity of the event processing system (a little). It might sometimes get the focus handling wrong though (but fixing that requires a restructure of the entire event handling engine, so not today).