Closed Bug 143540 Opened 22 years ago Closed 8 years ago

Make over-the-spot default for Japanese kinput2

Categories

(Core :: Internationalization, defect)

Other
Linux
defect
Not set
critical

Tracking

()

RESOLVED WONTFIX

People

(Reporter: warren, Assigned: smontagu)

Details

(Keywords: inputmethod)

Attachments

(1 file)

Mozilla does not behave properly with Japanese kinput2 input in Linux. 
 
Here is a screenshot of Netscape 4.7x working properly with kinput2 
http://www.mplug.org/archive/2002/kinput2_netscape_before.png 
Here is Mozilla working improperly with kinput2 (notice the bottom left) 
http://www.mplug.org/archive/2002/kinput2_mozilla_before.png 
 
The problem is that over-the-spot is not enabled by default like all other web browsers in Linux.  Could you 
please add this line to the default prefs.js in order to fix this problem? 
  
user_pref("xim.input_style", "over-the-spot"); 
 
This should not have a negative effect on anything else, right?
And if this change cannot be made, please document is better.  I agonized over this problem for over a year 
without finding a single page describing how to enable over-the-spot in Linux. 
QA Contact: ruixu → ylong
Change component from localization to internationalization.
Component: Localization → Internationalization
Change to i18n default owner.
Assignee: rchen → smontagu
Warren, what Linux flavor are you using and what is your default
Windows Manager?

See this bug for more info. If you're using Metacity Windows Manager,
you can upgrade it to a newer version to avoid the problem.

http://bugzilla.mozilla.org/show_bug.cgi?id=210134
Status: UNCONFIRMED → NEW
Ever confirmed: true
Warren, are you talking about the positioning of the IME manager
at the bottom, not the input inability problem as described in 
Bug #210134 ?
Attached patch PatchSplinter Review
Warren, I looked at this issue on Red Hat 7.3. What you're talking about
is just the IME control window, is that right? I see that when I press the
space bar and bring up Kanji candidates, the candidate window is much
closer to the input line and causes no problem in my opinion.

The IME control window only shows what state the IME is currently in, e.g.
Hiargana mode, Kanji mode and Seleciton mode. It does not seem to have
any effect on where the candidate selection window is. 

If this is the problem, I don't see that this is a big issue because
it does not have a practical effect on Japanese input action.

(Not related to the other bug, after all.)
"on-the-spot" is a preferred input style. We should change the default
only if there is an overrriding reason for it.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62307
Red Hat Linux 8 shipped with this user pref in mozilla-1.0.1 by default because
it fixed the position of the candidate selection and kinput2 input window from
the bottom left (hidden by taskbar) to right under the text input area.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=84859
Red Hat Linux 9 shipped with mozilla-1.2.1 without this user pref.  They tried
to get on-the-spot working properly with kinput2, but I suspect they ran out of
time.  Strangely that over-the-spot user pref no longer works with mozilla-1.2.1
through mozilla-1.4.

http://www.togami.com/~warren/archive/2003/rawhide_kinput2_bad.png
This is a screenshot today with mozilla-1.4 rc from on Red Hat Rawhide. 
over-the-spot user pref does nothing here.  RH8 and RH9's default window manager
is  metacity.
Warren, did you look at the comment #4 and Bug 210134? 
Katakai-san mentions in that bug that upgrading to a newer
version of Metacity solved his problem on RH8. RH9 ships with
a newer version of Metacity and kinput2 does not have the 
input problem. It would not be good if the candidate window is
way too low but that has not been my experience so far. 

What is the version of Red Hat Rawhide you're using and what is the
Windows manager?

ylong, can you check the pposition of the candidate on RH8? Can you
test this on RH 9 also?
> ylong, can you check the pposition of the candidate on RH8? Can you
> test this on RH 9 also?

If I modify the input style to over-the-spot, then I don't see the problem in
bug 210134 with 06-24 1.4 branch build.
But I don't have (also couldn't find) a RH9 to test.
The behavior for me in RH9 and Rawhide (near latest) is identical for me.  I
have NEVER been able to get on-the-spot to work in any version of Red Hat Linux,
while over-the-spot worked in RH73 and RH80 with the user pref option mentioned
above.

http://www.mplug.org/archive/2002/kinput2_mozilla_before.png
Note that the kinput2 window placement issue is not only the Candidate Selection
window, but also the status window (not sure what it is really called.)  This is
an older screenshot, but it still behaves exactly like this.  This screenshot
was from KDE using kwin window manager.

My current version of metacity is:
metacity-2.4.55-3

I am currently looking to test a newer version if available.
Warren, Katakai-san,

We need to clarify what the issues are, particularly with respect to
Bug 210134.

Warren, can your problem in this bug be described as follows:

1. The status window is too low on the lower left side of a monitor when
    the on-the-spot style is used.

2. The candidate selection window (for conversion) is also too low and away
from the real input location when on-the-spot style is used.

3. But the user can input characters even with these problems.

4. Bug 210134 is about the inability for users to input JA characters
   under RH 8 and this is not the issue raised in this bug.

Thanks!
> Warren, can your problem in this bug be described as follows:
> 1. The status window is too low on the lower left side of a monitor when
>    the on-the-spot style is used.

Yes, either with mozilla-1.2.1 or mozilla-1.4 default settings, or adding the
above option to prefs.js.  Also tried on-the-spot within that option syntax.

> 2. The candidate selection window (for conversion) is also too low and away
> from the real input location when on-the-spot style is used.

Yes.

> 3. But the user can input characters even with these problems.

Yes, it has worked fine in RH7.2 through RH9, only with the above annoyances. 
All KDE applications in these distributions seem to work with acceptable
behavior by default, as does evolution-1.4, but other apps like mozilla,
epiphany, galeon, or gedit do not and behave as described above.

> 4. Bug 210134 is about the inability for users to input JA characters
>   under RH 8 and this is not the issue raised in this bug.

I don't have any problem inputting JA characters in RH8, I haven't read through
210134 carefullly yet, reading now.
Using the default settings, the "Candidate Selection" menu is completely hidden
by the GNOME panel in RH9 if the panel is at the bottom of the screen (default
setting), so this is a serious issue.

No matter what is decided about this, it should be possible to change to/from
"over-the-spot" using some easily available setting in the prefs menu.
QA Contact: amyy → i18n
We don't have this prefs because we always use on-the-spot editing if possible.  Also this bug is too old era that uses xlib.  If user wants over-the-spot editing for any or all platforms, please file a new bug.
Status: NEW → RESOLVED
Closed: 8 years ago
Keywords: inputmethod
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: