Red Hat Bugzilla – Bug 62445
(Konqueror) Japanese kinput2 status doesn't show
Last modified: 2007-03-26 23:52:24 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020314
Description of problem:
When you use "kinput2 -canna &" to input Japanese, the kinput2 status window no
longer pops up below the text input location like it used to in KDE 2.2.2 and
still does in Netscape. Despite this, input and hiragana, katakana and kanji
alternate selection DOES WORK.
This screenshot shows how the kinput2 status window is supposed to show.
Version-Release number of selected component (if applicable):
Skipjack beta1 with up2date (3-27-2002)
Steps to Reproduce:
1. Run the Canna service.
2. Run "kinput2 -canna &"
3. Run "LANG=ja_JP.eucJP LC_ALL=ja_JP.eucJP XMODIFIERS="@im=kinput2" konqueror
4. Attempt to input Japanese after you hit SHIFT-SPACE.
Actual Results: kinput2 status window doesn't show, but input and alternate
Expected Results: kinput2 status window should show, right below the text input
Leon: Is this the effect of switching to onthespot by default?
It should have status window. cc'ing kinput2 maintainer to confirm.
overthespot is now the default and kinput2 should react correctly. it is in qt-3.0.3-6
Confirmation this is working?
It is somewhat fixed. Initially when I run "LANG=ja_JP.eucJP konqueror
http://www.google.co.jp", put the cursor in the textbox and hit SHIFT-SPACE,
no status window is visible. After you enter type a few characters and hit
ENTER, the characters and the status window appears. Afte that point the
status window works properly within that textbox.
Tested again in KDE 3.0.0-9. Behaves slightly different now.
[warren@riku warren]$ LANG=ja_JP.eucJP XMODIFIERS="@im=kinput2" konqueror
QGDict::hashKeyString: Invalid null key
QGDict::hashKeyString: Invalid null key
(Then Konqueror launches. What are these Invalid null key messages?)
SHIFT-SPACE does not display the kinput2 status window beneith the Google
textfield box until I entered a word and hit ENTER. Alternatively, it appears
immediately if I hit the right arrow key right after I SHIFT-SPACE. It also
appears immediately there if kinput2 is enabled, click on any link then click
The QCDict error message does not related to this.
From the description, it displays status window, but seems kinput2 may not
activate the status window before any action. Can kinput2 maintainter have a
look the kinput2 code see if there any related code segment that related to
Re-tested: Still exists in Red Hat 7.3 release.
Re-tested in Red Hat Limbo. Now the kinput2 status window NEVER appears in
Konqueror, although Japanese text input does work. Limbo also introduces Bug
68086 (regression of Bug 62446) where Japanese input text does not submit to Google.
Re-tested in Limbo2 kdebase-3.0.2-7.
Bug 68086 is fixed, but kinput2 status will still never displays within
Konqueror. Recommending higher priority because this makes it annoyingly
difficult to use Japanese in Konqueror.
qt-3.0.5-10 fixed the problem.
Tested with qt-3.0.5-10. It still appears to be broken. The kinput2 input
status does not show in Konqueror, but text input does work.
Is over-the-spot still enabled for Konqueror? I ask because the kinput2
alternate character candidate selection window pops up near the bottom left of
the screen rather than over-the-spot. This is somewhat like how Mozilla
behaved with kinput2 before over-the-spot was enabled by default in Red Hat's
Created attachment 70205 [details]
ja konqueror over the spot
Attached is the result from over-the-spot. Is it a okay result for japanese user?
You can also try to run "qtconfig". Go to "Interface" tab and try to choose different XIM
Which package contains qtconfig?
What is your LANG environment variable when kinput2 works properly for you? On
my system I used the following to run kinput2 and konqueror.
kinput2 -canna &
LANG=ja_JP XMODIFIERS="@im=kinput2" konqueror http://www.google.co.jp
My default LANG=en_US.UTF-8, but the above line should work properly. It did so
in Red Hat 7.2 witn Konqueror 2.2.2, and it does so now with Mozilla and many
qtconfig was in qt-devel but now it is in qt main package.
Look like kinput2 cannot get the interface placement position before any text is being
input (ie. placed over the visible pixels) If you type a letter before activate the IM
then it can be placed correctly.
We may need some debug results from kinput2.
(Keeping the component assignment to kinput2 package.)
When I type a letter before activating kinput2 with SHIFT-SPACE, it has no
difference in behavior for me.
I grabbed qt-devel-3.0.5-10 from Rawhide, and it contains qtconfig.
Tested different qtconfig XIM Input Styles:
On the Spot (default) doesn't work, alternate character selection doesn't in the
proper location like in Mozilla.
Over the Spot doesn't work either, and it puts the alternate character selection
window in another (wrong) place.
"Off the Spot" simply crashes when I attempt to run it with this error message:
Failed to create XIM input context!
zone still contained 2 blocks
The placement of the alternate character selection window when you hit SPACE
SPACE after typing some Japanese characters indicates that over-the-spot isn't
working properly. Try kinput2 with Mozilla for a comparison of how it should
work properly, then disable over-the-spot in Mozilla to see it behave just like
Konqueror in this regard.
Still broken in null.
Hmm, I wonder why this problem is assigned to kinput2.
On X, GTK+ and GNOME, kinput2's status window is shown without any input at the
correct possition because those applications are set spotLocation to the
appropriate place. I suspect Qt has this bug.
Does Qt do nothing until receiving something like input?
Bug 73331 related to this problem
On the problem of it cannot show status window in some form (I can able to
show the status window on www.yahoo.co.jp), it may related to konqueror. I am
looking on what produces this problem now.
For the second problem which shows in www.google.com:
position after focus, it cannot return the visable positions. That's why the preedit and
status cannot be visable. However, after the widget is drawn and if you refocus (switching
windows, etc). Because it contains the widget already so it can get the correct position
hence passing XNSpotLocation to XIM server correctly.
I don't see any real solution for the way that konqueror is handling html (Maybe change
It would be great if anyone with konqueror or web browser hacking expenience can shine
some lights on this problem.
* We can probably do a hack which will be something simliar to check for x and y, if
larger than the window (or maybe desktop size), just pass (0,0) for setting the ICValues
so at least it can show the preedit and status window within the current window.
Still broken in Phoebe.
posted to upstream