I18N - no visual feedback for input method in UML Document window
Product Version: NetBeans IDE Dev (Build 200710281200)
Java: 1.6.0_01; Java HotSpot(TM) Client VM 1.6.0_01-b06
System: SunOS version 5.11 running on sparc; UTF-8; ja_JP (nb)
To reproduce the problem:
1. create a UML project and create a Use Case diagram
2. open UML Document window if necessary
3. put a Use Case element on the diagram, and select the element
4. click in the Document window, and type Ctrl-Space to enable input method
5. type "aiue", then corresponding Hiragana characters appear
6. type Return to commit the string
7. type Ctrl-A to select all characters
8. type "o", then all Hiragana characters are erased, and empty
a Hiragana character, which corresponds to "o", should be there
9. type Return to commit this "o", then corresponding Hiragana appears
probably a duplicate of long standing issues, 78353, regarding uml design window
and input of multibyte; many things have been fixed and its known that
some things have not; for nb6 I believe the overall issue has been waived
and the workaround of using the properties window to compose and add the
uml team can decide if this one is a duplicate of that overall issue.
changing to p2 to match priority of other related issues on input of multibyte;
this still might be duplicate of existing open issues -
can uml team evaluate and see and close this one if it is ?
Reviewed and approved for waiver by UML -iteam.
does the upcoming changes to uml include new approach or api
for the areas that get user input, since for input of multibyte
characters there have been many problems and this one is an example ?
if the new things do not impact how the multibyte input is handled,
can this be fixed in trunk so we can then get it into the first 6.1 patch ?
(thats the process)
please fix for 6.5
In NB 6.1 & 6.5, I'm seeing the flashing vertical-bar cursor. Perhaps, this is solaris specific issue.
Works on windows, needs to be verified on solaris.
does it work ok for you now using uml for 6.5 ?
please use nb build of 0721 since more recently uml
builds are not in 6.5 ide, but the fix would be in build of 0721.
also, can you see if it looks ok for Chinese also, as to more complex
but normal input ?
The problem is still reproducible with trunk Build 200807281401
on Solaris Nevada SPARC and x86. See attached image. Preedit
character (in the circle) is positioned incorrectly and hidden.
This problem might not be reproduced with one try. I will try
Windows later to confirm if this problem is not reproducible.
Created attachment 65912 [details]
reopened based on Kasha's comments; also updated version
since it happens in 6.5 now.
Confirmed that this problem is still reproducible on Windows XP
SP2 with trunk Build 200807281401.
I'm able to reproduce the issue on Windows Vista with latest build and Microsoft Pinyin IME for simplified Chinese, but
only after more than 20 tries. The defect is very minor, once the selection is committed the character is repositioned
at the right place, and subsequent inputs are not affected. P3 or P4 would be more appropriate.
kasha, team is asking if this could be viewed as p3 as per Sheryl comments of today -
what do you think -
does it happen rarely
does it have little impact on other operatioms ?
is it a common ways of doing input for asian characters
and if so, if something is hidden from user seems like a big impact ?
we don't want to cause users in asian locales to do anything special or workaround
if when they are doing normal things; that seems to be a p2 kind of issue IMO.
I agree it is not a critical bug.
This problem happens frequently. The input operation is quite
normal. It is important for users to see what are being typed
in, as all typed characters are converted, then converted again,
and then user need to decide the result (candidate) is good, and
if not good, convert again.
But I do not think that UML Documentation feature is so
important to make this bug P2.
thanks for the comments.
I think other issues regrading input of multibyte in other parts of drawing area/design area
of diagram will be fixed going forward - from what I heard the new implementation of drawing
area dooes not include yet about the editing or input, so its possible the other existing
issues about mbyte input are still present also.
based on his comments, I agree its ok to make this p3.