Hi, Anton.
The fix looks fine.

On 17.06.15 18:46, Anton Nashatyrev wrote:
Hi Sergey,

    thanks for your suggestions!
could you please take a look at the updated fix: http://cr.openjdk.java.net/%7Eanashaty/8074882/9/webrev.01/

Thanks!
Anton.

On 08.06.2015 15:41, Sergey Bylokhov wrote:
Hi, Anton.
It is unclear from the documentation, what happen when one of the replaceStart/replaceEnd will contain correct range and another will be -1? Plus since this is an RFE, which adds a new functionality, I suggest to write a new tests for it.


On 12.04.15 13:57, Alexander Zuev wrote:
Looks fine to me.

/Alex

On 10 Apr 2015, at 15:12, Anton Nashatyrev <anton.nashaty...@oracle.com <mailto:anton.nashaty...@oracle.com>> wrote:

Hello,

   any volunteers to review?

Thanks!
Anton.

On 01.04.2015 18:43, Anton Nashatyrev wrote:
Hello,
   could you please review the following IM API extension proposal:

fix: http://cr.openjdk.java.net/~anashaty/8074882/9/webrev.00/ <http://cr.openjdk.java.net/%7Eanashaty/8074882/9/webrev.00/> <http://cr.openjdk.java.net/%7Eanashaty/8074882/9/webrev.00/>
bug: https://bugs.openjdk.java.net/browse/JDK-8074882

Problem: Press-and-hold Mac IM (when an accented char variant could be selected) couldn't be supported by the components other than TextComponent

MacOS Cocoa Input Method API supports the 'replacement range' parameter in its callbacks indicating what range of the committed text of the document should be replaced with the new composed text. In case of press-and-hold IM this parameter always indicates the previous char.

Fix: extends the IM API to support the 'replacement range'. The fix includes the new API, its implementation and adoption to the existing JTextComponent, the changes to be made in the MacOS code to conform the new API. The sample custom Java IM is attached to the JBS report to demonstrate the new API usage and test the implementation.

Thanks!
Anton.



--
Best regards, Sergey.



--
Best regards, Sergey.

Reply via email to