Japanese XIM input problem.(maybe Chinese, or Korean too?) : Hitting conversion key does not immediately update the converted result on screen

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

Japanese XIM input problem.(maybe Chinese, or Korean too?) : Hitting conversion key does not immediately update the converted result on screen

ISHIKAWA,chiaki
I am using TB 52.2.1 under Debian GNU/Linux.

I think since the earlier upgrade in July (or in June), I have had the
problem with Japanese input using XIM.

XIM protocol is a protocol to handle complex input handling via an external
program under X.
There are input methods for languages such as Japanese, Chinese and Korean
to use XIM.

In my case I use an external helper called kinput2-wnn (with local
modification for debugging an earlier issue).
This is enabled by one of the environmental variable settings below.
XMODIFIER=@im=kinput2
XMODIFIERS=@im=kinput2

When the XOMODIFIER(S) setting is above, and kinput2-wnn binary is run in
the background, and I run thunderbird (or FF),
I can invoke Japanese input for both TB and FF and it worked like a charm
until a month ago or so.

With the new version of TB in the last couple of months, the conversion
starts, but when I try to select  the next conversion candidate, the screen
is not updated at all.
It is as if the hitting the conversion key DOES proceed to obtain the next
conversion result internally, but however, somehow the immediate update
visually is not performed any more...
(I use On-The-Sport conversion scheme.)

When I hit NEWLINE so that the converted result is finalized, the display
then GETS UPDATED and I see that my earlier attempt to choose next
conversion candidate succeeded and so internally (to XIM?) and the final
newline brings out the final selection.

Or maybe somehow the event is not dispatched immediately and
the event for hitting the conversion key is queued somewhere and is not
immediately delivered to XI. And maybe XIM receive the events in a batch
after their getting queued up somewhere (?). This might explain the behavior
I see.

In any case, this makes the Japanese input almost useless for TB now (under
Debian GNU/Linux).
I checked and found that the FF has the same problem.

On the same PC, I checked the operation of Libreoffice impress presentation
program, and I can confirm that this strange behavior does not show up in
Libreoffice Impress. I can type Japanese into it, and the conversion and
display update work as expected.

The described problem  only shows up in FF and TB.

I am now trying to see if I can find people with similar afflictions to see
if the problem is not unique to my PC.

I use Japanese, and
I suspect Chinese (and maybe Korean) users are affected by this issue, also.

I am afraid that something needs to be fixed maybe in Qt or some other GUI
library.


TIA



_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird