Bug 84706 - kinput2: preedit characters don't follow resized window
kinput2: preedit characters don't follow resized window
Product: Fedora
Classification: Fedora
Component: kinput2 (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Akira TAGOH
Bill Huang
: i18n
Depends On:
  Show dependency treegraph
Reported: 2003-02-20 13:59 EST by James McDermott
Modified: 2014-08-24 20:55 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-17 23:32:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Program to reproduce the problem (7.13 KB, application/octet-stream)
2003-02-20 14:00 EST, James McDermott
no flags Details
program to reproduce problem. (6.38 KB, text/plain)
2003-02-20 14:03 EST, James McDermott
no flags Details

  None (edit)
Description James McDermott 2003-02-20 13:59:02 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830

Description of problem:
 Hardware Environment:
PIII 600MHz Mem 256MB

Software Environment:
OpSystem: RedHat7.2 and all Japanese supported distributions
Locale: ja_JP.eucJP
kinput2: version 3.0 and version 3.1 beta4

Preedit characters of kinput2 (Japanese Input Method) don't follow its target
window, when the main window was resized.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Set kinput2 to your InputMethod on Japanese locale.
1. Compile and run this sample code below on Japanese locale.
  Then, one window with one rectangle is shown.
2. Move mouse pointer in the rectangle.
3. Press Shift and Space key to activate kinput2
4. Input some characters and keep preedit status. Don't commit them.
5. Resize the main window

Actual Results:  Actual Results:
The preedit characters stay the original location.

Expected Results:  Expected Results:
The preedit characters should follow the target window.

Additional info:

Additional Information:
It looks kinput2 doesn't work, when the target window (not the main window) was
moved without its resizing.
The problem occurs on kinput2 only. It doesn't on other input methods, ATOK
X/htt or Wnn 7/xwnmo.
Comment 1 James McDermott 2003-02-20 14:00:58 EST
Created attachment 90222 [details]
Program to reproduce the problem
Comment 2 James McDermott 2003-02-20 14:03:16 EST
Created attachment 90223 [details]
program to reproduce problem.
Comment 3 Jeff Needle 2003-05-27 11:12:54 EDT
Can someone update this issue, please?  The Issue Tracker issue that originated
this is about to become 1 year old, without an update.
Comment 4 Akira TAGOH 2003-06-09 05:00:59 EDT
To clarify whether this is a bug or not, I need to read the XIM spec. the most
codes I know well is GTK+. GTK+ 1.2 did supports the over-the-spot like attached
code. Although I'm not sure if it's kinput2 bugs, the GTK+ 1.2 applications did
repositionning the preedit area, when it received the realize and size_allocate
events. in other words, the applications has a way to resolve this.
I'm not sure if this is MUST thing as the XIM spec at this point.
Comment 5 Akira TAGOH 2003-06-24 07:47:56 EDT
Well, I got a advice. the specification of XIM Protocol didn't mention that who
should be handling the focus window, how should notify the preedit location,
where should be done. we have some solution. but as a lot of apps like gtk1.2
does, most easy and no effects for other apps is the XIM client relocates the
preedit line. I'm not sure how other solution affects all of XIM client. so I
can't fix this soon, and this problem can be fixed in the client side so that
the XIM spec is ambiguous.
Set a low priority and a low severity.
Comment 6 Akira TAGOH 2005-03-17 23:32:55 EST
Since it's deprecated in current release, and we'd recommend to use IIIMF
instead of, it's hard to have a time to fix this ATM.

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