Unable to compose Japanese text in property pane

[GoogleCodeExporter]

What steps will reproduce the problem?
1. In property pane,
2. Enable Japanese input method
3. and try to enter any Japanese text.

What is the expected output? What do you see instead?
Expected:
Uncommited composed text (with underline) is to appear.
For example, if you enter "てすと", the same text with underline shall 
appear in the plot pane, or nothing appears before you commit entered text.

Instead:
Input text is forcibly committed for each key type.
In the example, entered text is committed for each key press, and wrong text 
"てsてすてすtてすと" appears in the plot pane like in an attached image.

What version of the product are you using? On what operating system?
Umlet 11.3 on Windows XP professional SP3 32bit
Umlet 11.3 on Windows 7 professional SP1 32bit

Please provide any additional information below.
Here is a quick hack patch attached that changes update timing of GUI to 
keyTyped event instead of keyReleased event.

Original issue reported on code.google.com by h.sk...@gmail.com on 21 Jan 2012 at 8:23

Attachments:

• JapaneseIMIssue.png
• JapaneseIMIssue.patch

[GoogleCodeExporter]

Are you talking about the squares which are shown in the properties pane 
instead of the UTF-8 characters?

We think this is a problem with the jsyntaxpane we use for highlighting and 
code completion in plotlet. Perhaps there will be a new version anytime soon 
which fixes the problem.

As a temporary fix, you can go into OwnSyntaxPane.java and uncomment the line 
#81
this.setContentType("text/propertypanel");

Then you have the default JEditorPane which has no problem in showing special 
characters

I don't really get what's your patch file about. Could you please explain what 
should be fixed by applying it? Thanks.

Original comment by AFDiaX on 11 Feb 2012 at 6:50

[GoogleCodeExporter]

> Are you talking about the squares which are shown in the properties pane 
instead of the UTF-8 characters?

No, this is another problem.

While using Japanese input method, if we want to input "てすと" we will type 
"tesuto".
But if keyReleased method is used to get input characters, this method is 
called for every key type "t" "e" "s" "u" "t" "o", and we get an unexpected 
output.
On the other hand, if keyTyped method is used instead of keyReleased method, 
keyTyped methed is called only after composed text is committed using Japanese 
input method, and for every key type while input methods are not used, and we 
can get a right result.

My patch fixes this problem by changing to use keyTyped method instead of 
keyReleased.

Thank you.

Original comment by h.sk...@gmail.com on 12 Feb 2012 at 6:10

[GoogleCodeExporter]

Thanks for the comment, I didn't knew that.

To fix the problem, I think, I will switch keyTyped and keyReleased.
I think it's the more common approach anyway.

Original comment by AFDiaX on 12 Feb 2012 at 10:33

[GoogleCodeExporter]

It's fixed in r96 if we don't recognize any other problems by switching those 2 
methods

Original comment by AFDiaX on 12 Feb 2012 at 10:36

• Changed state: Fixed
• Added labels: UMLet-11.4

[GoogleCodeExporter]

Thanks a lot for fixing the problem.

Original comment by h.sk...@gmail.com on 12 Feb 2012 at 12:34

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The bugfix screwed up some timings (we used keyReleased to make sure the 
updated text in the properties panel is also updated in the element).

I will reopen this issue for the moment

Original comment by AFDiaX on 20 Feb 2012 at 2:33

• Changed state: Started
• Removed labels: UMLet-11.4

[GoogleCodeExporter]

I confirmed r121, but unfortunately the problem is not fixed.
The key point of this problem is typed keys (ex."t""e""s""u""t""o") and 
characters to input ("てすと") are not same.
Therefore, we will get an unintended result if updateGridElement() is called 
from keyReleased().

And, getKeyChar() will be used in keyTyped() instead of getKeyCode(), because, 
by Oracle's Java SE documentation, getKeyCode() always returns VK_UNDEFINED for 
key typed event.

Thanks.

Original comment by h.sk...@gmail.com on 3 Mar 2012 at 2:06

[GoogleCodeExporter]

I know your problem, but the solution isn't that simple, because if I use 
keyTyped() instead of keyReleased(), the text in the properties panel will not 
be updated before the visible diagram gets updated.

eg: if I type "*boldtext*" in the properties, it will not be bold until the 
next time I press a key.

This is the reason why I have reopened the issue for the moment.

Original comment by AFDiaX on 3 Mar 2012 at 6:35

[GoogleCodeExporter]

Hi

I think I have finally found the problem. As every other Swing Update, it 
should be done using SwingUtilities.invokeLater.
Then the keyTyped event works as expected :)

So the problem should be finally fixed in r122

Original comment by AFDiaX on 3 Mar 2012 at 7:44

• Changed state: Fixed
• Added labels: UMLet-11.5

[GoogleCodeExporter]

By the way the squares will also be fixed in UMLet 11.5 (it was a font problem)

Original comment by AFDiaX on 3 Mar 2012 at 7:45

[GoogleCodeExporter]

I tested r132 and it works correctly.
Thank you!

Original comment by h.sk...@gmail.com on 11 Mar 2012 at 7:16