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.