Workaround for unexpected commitment of the node text when inpputting Japanese via IME on inline-edit.

[hokorobi]

Although I input Japanese using IME, if setLineWrap() is performed, inputting text will be comitted against an intention.
For this reason, during the IME input, it changed so that setLineWrap() might do nothing.

[dpolivaev]

Hello,

unfortunately I was not able to find sufficient information about InputMethodEvent and AttributedCharacterIterator. I do not understand the intention of the code and check it. Could you please explain here what it is supposed to do and may be provide some references where I can learn more about it. I am asking you to help me because I want to be sure that I understand the code and can maintain it myself.

Regards, Dimitry

[dpolivaev]

Well, actually I want to understand

• when method inputMethodTextChanged is called,
• what is the difference between "composed text" and "committed text" mentioned in description of Class InputMethodEvent
• why value returned by getEndIndex() is used but getBeginIndex() is not called
• how I can reproduce it under Windows

[hokorobi]

Hello,
Thank you for your interest.

when method inputMethodTextChanged is called

Inputted text by IME. http://en.wikipedia.org/wiki/Input_methodI
(I use Google IME. http://www.google.co.jp/ime/ , http://www.tofugu.com/2011/02/16/google-japanese-ime-for-better-typing-in-japanese/)
The processing outputted according to an input is added and I have attached image of the result of having inputted the text.

        public void inputMethodTextChanged(InputMethodEvent event) {
            System.out.println("+++ committed:"+committedLen+"/"+inputLen);

typed: konnitihasekai

typed: {Space} (convert trigger)

what is the difference between "composed text" and "committed text" mentioned in description of Class InputMethodEvent

typed: {Down} (partly committed)

typed: {Down} (whole committed)

[hokorobi]

InputMethodEvent: http://docs.oracle.com/javase/7/docs/api/java/awt/event/InputMethodEvent.html
AttributedCharacterIterator: http://docs.oracle.com/javase/7/docs/api/java/text/AttributedCharacterIterator.html

why value returned by getEndIndex() is used but getBeginIndex() is not called

It is because I thought that the number of input characters was acquirable only by getEndIndex().
http://docs.oracle.com/javase/7/docs/api/java/text/CharacterIterator.html#getEndIndex()

how I can reproduce it under Windows

I'm sorry, it seems that you have to have serious work done.
http://www.yesjapan.com/video/pages/install-japanese-windows-7-vista.html

[vboerchers]

how I can reproduce it under Windows

Dimitry, maybe you don't have to be able to reproduce it - as long as the change doesn't break input for others our Japanese (and Chinese?) users could test the IME part.

I remember people asking for improvement for IME and it's great that we have a helping hand here.

[hokorobi]

Hello,

If I wrote information which is not enough, please let me know.

Regards, hokorobi

[dpolivaev]

Thank you very much four the message. The reason for the things slowing down is that we want to change our release status to release candidate and it is not a good time for merging in issues which I can not test and support by myself. In addition I do not understand your solution at the point where you take getEndIndex() instead of the difference getEndIndex() - getBeginIndex() . It may be right, I don't know, have you tested your solution if you edit an existing text and add text to it?

So I decided not to merge your pull request into the release branch to get time for testing by users and bug fixing. I do appreciate your contribution, I just do not like to take the risk right now.

Regards, Dimitry

[hokorobi]

I understood. I think that it is the right judgment.

In addition I do not understand your solution at the point where you take getEndIndex() instead of the difference getEndIndex() - getBeginIndex() . It may be right, I don't know, have you tested your solution if you edit an existing text and add text to it?

I consider once again.

[hokorobi]

As long as I tested, getBeginIndex() always returns 0.
So, both of getEndIndex() - getBeginIndex() and getEndIndex() return the same.
In order that there may be no timing to iterate, this result has agreed with anticipation.

Regards, hokorobi

[vboerchers]

Some Questions:

1. Is it actually necessary to setup a complete Japanese language environment or wouldn't it suffice to add another keyboard

   http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/input_kbd_add_kbd_layout.mspx?mfr=true

2. Is it important to use Google IME for the test?

3. There is no undo/redo support for the in-line (not pop-up) editor. If we wanted to have that we might have to commit the editor content more than once anyhow.

[hokorobi]

1. That is probably possible. But, I think that use of IME is indispensable.
2. It is not important to use Google IME. MS-IME can also be tested.
3. I agree.

[dpolivaev]

I refactored your code and integrated it into the master branch. But I was not able to test it because I do not use IME myself.

Could you please check the solution in commit 4b3549f ?

[hokorobi]

Thank you very much, Dimitry.
It works correctly on Windows 7 HomePremium x64 + Google IME and Windows 7 HomePremium x32 + Microsoft IME.