Bug 62445 - (Konqueror) Japanese kinput2 status doesn't show
(Konqueror) Japanese kinput2 status doesn't show
Status: CLOSED UPSTREAM
Product: Red Hat Linux
Classification: Retired
Component: kdelibs (Show other bugs)
9
All Linux
high Severity medium
: ---
: ---
Assigned To: Ngo Than
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-03-31 22:05 EST by Warren Togami
Modified: 2007-03-26 23:52 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-27 22:24:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
ja konqueror over the spot (61.23 KB, image/png)
2002-08-12 20:05 EDT, Leon Ho
no flags Details

  None (edit)
Description Warren Togami 2002-03-31 22:05:22 EST
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.
http://www.mplug.org/archive/2002/kinput2_netscape_after.png


Version-Release number of selected component (if applicable):
Skipjack beta1 with up2date (3-27-2002)

How reproducible:
Always

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
http://www.google.co.jp"
4. Attempt to input Japanese after you hit SHIFT-SPACE.

Actual Results:  kinput2 status window doesn't show, but input and alternate
selection works.

Expected Results:  kinput2 status window should show, right below the text input
location.
Comment 1 Bernhard Rosenkraenzer 2002-04-01 04:08:19 EST
Leon: Is this the effect of switching to onthespot by default?
Comment 2 Leon Ho 2002-04-01 19:02:53 EST
It should have status window. cc'ing kinput2 maintainer to confirm.

Comment 3 Leon Ho 2002-04-03 04:01:32 EST
overthespot is now the default and kinput2 should react correctly. it is in qt-3.0.3-6
Comment 4 Jay Turner 2002-04-03 11:11:15 EST
Confirmation this is working?
Comment 5 Warren Togami 2002-04-05 20:28:40 EST
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. 
Comment 6 Warren Togami 2002-04-14 07:07:19 EDT
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.
Comment 7 Leon Ho 2002-04-15 02:35:33 EDT
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?
Comment 8 Warren Togami 2002-05-09 04:08:15 EDT
Re-tested: Still exists in Red Hat 7.3 release.
Comment 9 Warren Togami 2002-07-15 07:38:34 EDT
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.
Comment 10 Warren Togami 2002-08-07 06:42:43 EDT
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.
Comment 11 Leon Ho 2002-08-11 20:46:52 EDT
qt-3.0.5-10 fixed the problem.
Comment 12 Warren Togami 2002-08-12 04:48:40 EDT
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.
Comment 13 Leon Ho 2002-08-12 20:05:08 EDT
Created attachment 70205 [details]
ja konqueror over the spot
Comment 14 Leon Ho 2002-08-12 20:07:10 EDT
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. 
Comment 15 Warren Togami 2002-08-12 20:13:43 EDT
Which package contains qtconfig?
Comment 16 Warren Togami 2002-08-12 20:19:46 EDT
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.
Comment 17 Leon Ho 2002-08-12 20:59:30 EDT
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.) 
Comment 18 Warren Togami 2002-08-12 22:15:55 EDT
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.
Comment 19 Warren Togami 2002-09-02 05:42:11 EDT
Still broken in null.
Comment 20 Akira TAGOH 2002-09-02 07:33:17 EDT
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?
Comment 21 Leon Ho 2002-09-02 22:35:19 EDT
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.
Comment 22 Leon Ho 2002-09-03 09:46:26 EDT
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.  
Comment 23 Warren Togami 2002-12-24 00:50:13 EST
Still broken in Phoebe.
Comment 24 Leon Ho 2003-04-27 22:24:31 EDT
posted to upstream
http://bugs.kde.org/show_bug.cgi?id=52685

Note You need to log in before you can comment on or make changes to this bug.