[BUG] Japanese Input Method uim-skk doesn't work properly.

uim-skk doesn't work properly.
This problem occurs in all input fields.
The problem is not yet fixed though I submitted the report of DSK-333391 and DSK-345019 before.
uim-skk uses the CTRL-key for conversion.

The key that doesn't work properly is the following.

ctrl + m, ctrl + j commit
ctrl + [, ctrl + g cancel
ctrl + n next candidate
ctrl + p previous candidate
ctrl + a beginning of preedit
ctrl + e end of preedit
ctrl + k erase after cursor
ctrl + u erase before cursor
ctrl + h backspace
ctrl + d delete
ctrl + b go left
ctrl + f go right
ctrl + q commit as fullwidth alphanumeric
ctrl + u commit as opposite case in latin coversion

When the ctrl key is pushed while converting it, the character is fixed.
For instance, you want to type "日本語",
<incorrect>
1. Press zenkaku/hankaku-key
2. Type Nihonngo → ▽にほんご is displayed.
3. Press Space-key → ▽にほんご is converted into ▼日本語.
4. press Ctrl+j-key → ▼日本語 is typed in.

<correct>
1. Press zenkaku/hankaku-key
2. Type Nihonngo → ▽にほんご is displayed.
3. Press Space-key → ▽にほんご is converted into ▼日本語.
4. press Ctrl+j-key → 日本語 is typed in.

If you make a mistake in typing the character,
<incorrect>
1. Press zenkaku/hankaku-key
2. Type Nihonngoo → ▽にほんごお is displayed.
3. press Ctrl+h-key → ▽にほんごお is displayed.
3. Press Space-key → ▽にほんごお is displayed.
4. press Ctrl+j-key → ▽にほんごお is displayed.

<correct>
1. Press zenkaku/hankaku-key
2. Type Nihonngoo → ▽にほんごお is displayed.
3. press Ctrl+h-key → ▽にほんご is displayed.
4. Press Space-key → ▽にほんご is converted into ▼日本語.
5. press Ctrl+j-key → 日本語 is typed in.

You will understand not to accept the operation with the ctrl key at all.
The problem that the caret position makes a mistake exists, too.
This is a bug that keeps being disregarded since version 10.60 that eliminated Qt dependency.
This bug doesn't occur in firefox, chrome, leafpad, emacs and others.
Please do not disregard the confirmation even if the number of reports of these problems is little.

In my English language skill, this is an utmost report.

***************************
Debian Squeeze x86_64
Openbox: 3.4.11.1-1
uim-skk: 1:1.5.7-9.1
Opera11.60 beta - build 1159

Have you posted this to the Japanese Opera forum? Some of the posters speak English. I think there are a couple of Opera Japan employees participating. Last time I posted there, though, they seemed reluctant to support anything but ibus.

In any case, IME does not always work with Opera on Linux. I've never been able to type Japanese into textboxes on Opera for a year or so. (I was able to do that on Opera 8.50 or so, but not after that.) I have to type Japanese text on a text editor and copy-and-paste it onto Opera.

The priority of ctrl key to uim-skk is a problem though I can type Japanese when the substituted key is used.
I have posted this to Japanese Opera forum.
They don't report whether it is bug even if half a year is passed though they have answered, "Please let me examine it".
I know that there is not the duty that they answer all articles.
I think that they should report on the result afterwards because they said, "Please let me examine it".
Because I had thought the staff of Japanese Opera Forum to be distrust, I posted this in this forum.

I think this problem to be improved by giving uim-skk the priority of the ctrl key from Opera when uim-skk is started in the text area(addressbar, searchbox, etc).
I doubt whether this problem is told to the developer by the staff in Japan Opera Forum.

The method of reproducing this problem did an additional report to DSK-345019.
Please fix this bug.


@furue
uim-anthyは試してみました？ テキストエリアでの日本語入力はできたと思いますよ。ただし、uim-anthyもctrlキーに問題はあるかも。
見当はずれのことを言っていたら、ごめんなさい。ちなみに、$im-switch -c でuimを選択しています。

The version of Opera that doesn't work properly uim that can be confirmed from the list of http://ftp.opera.com/pub/opera/linux/ is as follows.
1053b1,1060,1060b1,1061,1062,1063,1100,1100b1,1101,1110,1110b1,1111,1150,1150b1,1151,1152,1160,1160b1 and of course, all build of opera12 doesn't work either.
This bug is not improved at all though I am sending bug report many times.
Opera team keeps disregarding it without answering still though this is a critical bug for Japanese users.
I am disappointed at the correspondence of opera team.
Opera team seem to be always correcting the skin bug of 1px without looking round other bugs.
The share of opera where a lot of bugs have been left won't expand.Leastwise in Japan.

Originally posted by 7l2um:

This bug is not improved at all though I am sending bug report many times.Opera team keeps disregarding it without answering still though this is a critical bug for Japanese users.

I sympathize with you, which is the only (potentially) helpful comment I can offer.

In addition to the Japanese input problem(s), there are some other signficant perennial problems with Opera on Linux, significant in terms of the severity to the users. They are disregarded mainly because there are not many users affected by them. We are minority and minority is disregarded.

This comment is of course a speculation on my part; there is no solid evidence. I, however, think that this is the only consistent explanation for the phenomenon we are seeing.

It is the more frustrating that the developers don't explain their position. I wish they published semi-official comments that this and that bugs aren't actively worked on because this and that.

Having said that, I think you may be able to slightly increase your chance of being listened to, if you switch to ibus. It seems to me that ibus is (currently) regarded as the IME of the future and so I guess the developers are less willing to deal with other IMEs. (Here again, if they officially said they are more willing to look at ibus-related bugs than at other IME bugs, we would know better.)

We are just groping in the dark, without knowing if there is light somewhere.