Closed
Bug 143540
Opened 22 years ago
Closed 8 years ago
Make over-the-spot default for Japanese kinput2
Categories
(Core :: Internationalization, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: warren, Assigned: smontagu)
Details
(Keywords: inputmethod)
Attachments
(1 file)
592 bytes,
patch
|
Details | Diff | Splinter Review |
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?
Reporter | ||
Comment 1•22 years ago
|
||
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.
Comment 2•22 years ago
|
||
Change component from localization to internationalization.
Component: Localization → Internationalization
Comment 4•21 years ago
|
||
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
Comment 5•21 years ago
|
||
Warren, are you talking about the positioning of the IME manager at the bottom, not the input inability problem as described in Bug #210134 ?
Assignee | ||
Comment 6•21 years ago
|
||
Comment 7•21 years ago
|
||
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.)
Comment 8•21 years ago
|
||
"on-the-spot" is a preferred input style. We should change the default only if there is an overrriding reason for it.
Reporter | ||
Comment 9•21 years ago
|
||
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.
Comment 10•21 years ago
|
||
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?
Comment 11•21 years ago
|
||
> 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.
Reporter | ||
Comment 12•21 years ago
|
||
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.
Comment 13•21 years ago
|
||
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!
Reporter | ||
Comment 14•21 years ago
|
||
> 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.
Comment 15•19 years ago
|
||
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.
Updated•15 years ago
|
QA Contact: amyy → i18n
Comment 16•8 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•