Bug 62445

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 
http://www.google.co.jp 
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 
Back.

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 
this?

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 
mozilla package.

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 
input style. 

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
other programs.

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?

First problem: 
Bug 73331 related to this problem 
 
Second 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: 
I have debugged and found out javascript focus() is causing the problem. AFAIS, konqueror 
executes javascript 'before' the widget is being drawn, hence when it updates the compose 
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 
the whole lot of code which don't render and execute javascript as it parsing the html?). 
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
http://bugs.kde.org/show_bug.cgi?id=52685