Hi, Prasanta.
The same question about this code:
281 Rectangle r = getReq().getTextLocation(offset);
The getReq() returns InputMethodRequests which is implemented by a
number of classes, and I think one of them "InputMethodRequestsHandler"
returns scaled values from "getTextLocation()" already.
Some of these classes may return some stubs which should not be scaled,
like in CompositionAreaHandler:
// passive client, no composed text, so fake a rectangle
return new Rectangle(0, 0, 0, 10);
On 27/03/2018 22:39, Prasanta Sadhukhan wrote:
Any more comments?
Regards
Prasanta
On 3/26/2018 1:21 PM, Prasanta Sadhukhan wrote:
Hi Sergey,
On 3/23/2018 3:44 AM, Sergey Bylokhov wrote:
Hi, Prasanta.
Did you check why the "InputMethodContext.getTextLocation()" returns
non-scaled rectangle? Maybe we should do this inside
InputMethodContext()?
Yes, this code
http://hg.openjdk.java.net/jdk/client/annotate/f46bfa7a2956/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#l5673
scales down x,y as part of JDK-8073320 fix.
I have moved the fix to InputMethodContext as suggested
http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.02/
Regards
Prasanta
On 20/03/2018 22:17, Prasanta Sadhukhan wrote:
Hi Krishna,
Yes, I did not provide any since the testcase needs to be manual and
would have to contain lots of instructions of how to install
Japanese language and changing the input mode to hiragana
and also similar fix of input method earlier did not have a testcase
for similar reason.
Regards
Prasanta
On 3/20/2018 8:42 PM, Krishna Addepalli wrote:
Hi Prasanta,
Now the changes look fine. However, I noticed that there is no
testcase associated with this fix. Is that intentional?
Thanks,
Krishna
*From:*Prasanta Sadhukhan
*Sent:* Tuesday, March 20, 2018 5:04 PM
*To:* Krishna Addepalli <krishna.addepa...@oracle.com>;
swing-dev@openjdk.java.net
*Subject:* Re: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid
position of candidate pop-up of InputMethod in Hi-DPI on Windows
Thanks Krishna for your comment. Modified webrev catering to
retrieval of scalefactor of the active monitor being shown
http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.01/
<http://cr.openjdk.java.net/%7Epsadhukhan/8189687/webrev.01/>
Regards
Prasanta
On 3/20/2018 2:40 PM, Krishna Addepalli wrote:
Hi Prasanta,
I have couple questions regarding your fix:
1.The AffineTransform object should be retrieved from the Screen
on which the window is showing, whereas in your fix, you are
directly getting it from the default screen. In multi screen
environment, it may not be aligned correctly.
2.Is there any reason to retrieve the object in the top. I mean,
the AffineTransform object can be declared inside the “if
(haveActiveClient())” block, at the point of use.
Thanks,
Krishna
*From:*Prasanta Sadhukhan
*Sent:* Tuesday, March 20, 2018 1:01 PM
*To:* swing-dev@openjdk.java.net
<mailto:swing-dev@openjdk.java.net>
*Subject:* <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid
position of candidate pop-up of InputMethod in Hi-DPI on Windows
Hi All,
Please review a fix for an issue where it is seen that
for Japanese IME on windows 10 with scaleFactor 1.5, when we enter
text using IME popup, the popup is positioned on top of text,
thereby obscuring it
as seen in this screenshot.
Proposed fix is to apply the scaleFactor on the candidate's popup
positional coordinates x,y to generate proper coordinates to show
this popup
webrev: http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/
<http://cr.openjdk.java.net/%7Epsadhukhan/8189687/webrev.00/>
The screenshot after the fix is
Regards
Prasanta
--
Best regards, Sergey.
