date:20171127

Re: [10] JDK-8146537: TrayIcon Action Listener doesnt work in WIndows 10

2017-11-27 Thread Shashidhara Veerabhadraiah

Hi Sergey, Here is the Webrev containing fixes for your comments.

http://cr.openjdk.java.net/~sveerabhadra/8146537/webrev.01/

Thanks and regards,
Shashi

-Original Message-
From: Sergey Bylokhov 
Sent: Wednesday, November 22, 2017 4:31 AM
To: Shashidhara Veerabhadraiah ; 
awt-dev@openjdk.java.net
Subject: Re: [10] JDK-8146537: TrayIcon Action Listener doesnt work in WIndows 
10

Hi, Shashi.
On 20/11/2017 02:10, Shashidhara Veerabhadraiah wrote:
> Summary: The windows GetKeyState() api provides the key state of the 
> requested key as of that instant by sampling the current thread's key 
> messages from the message queue. Any misses either a thread ran faster 
> or slower it is possible to miss the key messages. This is the problem 
> that's happening under windows 10 wherein the key states are being 
> null for the mouse button press. This problem is mentioned in the msdn 
> as well. On the other hand, a tray icon message click produces 
> NIN_BALLOONUSERCLICK event only upon the left mouse button click and 
> hence there is no check required for the same.

The old code also request the state of the different keys like shift, control, 
etc. And after the fix we lose this information, probably we should apply it on 
top of the modifiers?

Another unclear thing is that we use
java_awt_event_InputEvent_BUTTON1_DOWN_MASK which is a mask for InputEvent as 
modifier for ActionEvent which does not have such mask.

--
Best regards, Sergey.

Re: [10] Review request for JDK-8158366: [macosx] Regression: closed/java/awt/dnd/RecognizedActionTest/RecognizedActionTest.html fails

2017-11-27 Thread Ajit Ghaisas

Hi Manajit,

 

   The changes look good.

 

As this is a new test in open, can you please confirm whether it passes on 
Windows and Linux as well?

 

Regards,

Ajit

 

From: Manajit Halder 
Sent: Monday, November 27, 2017 4:35 PM
To: Ajit Ghaisas
Cc: Prem Balakrishnan; Sergey Bylokhov; awt-dev@openjdk.java.net
Subject: Re:  [10] Review request for JDK-8158366: [macosx] 
Regression: closed/java/awt/dnd/RecognizedActionTest/RecognizedActionTest.html 
fails

 

Hi Ajit,

 

Modified the code as per your review comments.

Please review the changes.

 

http://cr.openjdk.java.net/~mhalder/8158366/webrev.01/

 

Thanks,

Manajit

 

On 27-Nov-2017, at 1:50 PM, Ajit Ghaisas mailto:ajit.ghai...@oracle.com"ajit.ghai...@oracle.com> wrote:

 

1) This test lacks copyright banner at the top
2) init() prints to System.err & returns silently in case of failure - suggest 
to capture failure and throw exception.

Regards,
Ajit

-Original Message-
From: Prem Balakrishnan 
Sent: Monday, November 27, 2017 12:02 PM
To: Sergey Bylokhov; Manajit Halder
Cc: HYPERLINK "mailto:awt-dev@openjdk.java.net"awt-dev@openjdk.java.net
Subject: Re:  [10] Review request for JDK-8158366: [macosx] 
Regression: closed/java/awt/dnd/RecognizedActionTest/RecognizedActionTest.html 
fails

+1

Regards,
Prem

-Original Message-
From: Sergey Bylokhov 
Sent: Friday, November 24, 2017 1:16 PM
To: Manajit Halder mailto:manajit.hal...@oracle.com"manajit.hal...@oracle.com>; Prem Balakrishnan 
mailto:prem.balakrish...@oracle.com"prem.balakrish...@oracle.com>
Cc: HYPERLINK "mailto:awt-dev@openjdk.java.net"awt-dev@openjdk.java.net
Subject: Re: [10] Review request for JDK-8158366: [macosx] Regression: 
closed/java/awt/dnd/RecognizedActionTest/RecognizedActionTest.html fails

Looks fine.

On 23/11/2017 02:05, Manajit Halder wrote:



Bug:
https://bugs.openjdk.java.net/browse/JDK-8158366
Webrev:
http://cr.openjdk.java.net/~mhalder/8158366/webrev.00/




-- 
Best regards, Sergey.

Re: [OpenJDK 2D-Dev] [10] Review Request: 8182410, 8183508, 8181289

2017-11-27 Thread Sergey Bylokhov


On 27/11/2017 14:02, Semyon Sadetsky wrote:

 > The current changes get my "+1" as comformant HTML5.

This is not true.  The empty  tags produce warnings in HTML5 validator:

https://validator.w3.org/nu/?doc=http%3A%2F%2Fcr.openjdk.java.net%2F~ssadetsky%2F8181289%2Fjdoc%2FmodB-summary.html


The warnings in the link above are about "name attribute" which was 
deprecated and obsolete in html5. And this is one of the warning which 
is reviewed here. I suggest you to check the files which are under 
review after the current patch applied.


--
Best regards, Sergey.

Re: [OpenJDK 2D-Dev] [10] Review Request: 8182410, 8183508, 8181289

2017-11-27 Thread Semyon Sadetsky

> The current changes get my "+1" as comformant HTML5.

This is not true. The empty tags produce warnings in HTML5 validator:

https://validator.w3.org/nu/?doc=http%3A%2F%2Fcr.openjdk.java.net%2F~ssadetsky%2F8181289%2Fjdoc%2FmodB-summary.html

-phil.

On 11/22/2017 07:58 PM, Jonathan Gibbons wrote:

Semyon,

You may indeed have explained why the behavior as it is, but we
cannot and should not link this review with changes to the javadoc
stylesheets, when the specific changes in the review are gratuitous
and not necessary in the first place.

Yes, we may separately, and later, look at how the javadoc manages
the header. Until then, I recommend that we stay within guidelines
that are fully conformant HTML5, and without visual issues with the
existing stylesheet.

So, I want to end this back and forth. I've spent enough time on
this. I've given my review feedback, which remains to not introduce
changes which may cause visual issues. If you and the AWT team want
to proceed with those changes, I'm done.

-- Jon

On 11/22/17 7:46 PM, Semyon Sadetsky wrote:

Jon,

This is because you have fixed page header. For me it works equally
in all browsers. I see no discrepancy between Chrome and Firefox on
my Linux platform. I believe that the stylesheet.css you have in
those examples does the magic :

a[name]:before, a[name]:target, a[id]:before, a[id]:target {
content: "";
display: inline-block;
position: relative;
padding-top: 129px;
margin-top: -129px;
}

so nothing specific comes from browser or "

I think the next link may help you

http://nicolasgallagher.com/jump-links-and-viewport-positioning/demo/

--Semyon

On 11/22/2017 02:53 PM, Jonathan Gibbons wrote:

Semyon,

I have reconstructed a very simple, very artificial example to demo
the bug. This example uses lots of filler text, but while that is
artificial, for sake of recreating a demo, note that the problem
first appeared, for real, in real JDK 9 API documentation with
extended doc comments, and that as a result, we followed the advice
I have been trying to give you.

See the toy API bundle here:
http://cr.openjdk.java.net/~jjg/semyon/api/overview-summary.html

There are two modules, modA and modB. Both have huge long doc
comments, with a heading at the top and a link at the bottom.

In modA, the anchor is of the form . In modB, the
anchor is of the form .

In each of these files, scroll to the end of the comment, and look
for a link, called "link", at the bottom of the page. In both
cases, the page scrolls so that the heading is near the top of the
browser window, but in one case it is hidden under the javadoc
navbar, and in the other case, it is clearly visible, below the
javadoc navbar.

This is the difference in behavior that I can been trying to
describe to you. I'm using Ubuntu 14.04 with Firefox 38, but I'm
not the only one to have seen this effect. I don't know whether
you will get the same effect in your browser, but the fact that
there is a reasonable OS/browser combo that demonstrates the
problem is enough of a reason to avoid provoking the problem
unnecessarily. If you don't see the problem on your browser, but
want to see it in mine, I see you are in SCA22, so drop by my
office for a demo.

I'll leave it to the AWT team to decide what to do about this
bug/review. I still recommend updating what is necessary to fix
issues, and not otherwise changing the doc comments unnecessarily,
and not changing them in a way to provoke this bad behavior.

-- Jon

On 11/22/2017 12:10 PM, Semyon Sadetsky wrote:

Hi Jon,

This is not only about HTML5 spec, I also hardly can find
resources that follow your "

You are correct that there is no bug here. But a bug was absent
before this fix as well. This bug is about following to the HTML5
standards, so let's follow them in full and not to return to this
once again. We have a good chance to provide documentation in
clean HTML5 after the fix without any workarounds.

--Semyon

On 11/14/2017 09:16 AM, Jonathan Gibbons wrote:

Semyon,

I read the HTML 5 spec the same as you, and we (on the Javadoc
team) started using id on other elements, as well as to
provide a target that could be linked to.

However, the pragmatic experience was that the scrolling in some
browsers did not completely reveal the element when there was a
layered z component involved: the target element sometimes ended
up under that layered component. Our experience was that the
behavior was fixed when the target identifier was in an element.

So, yes, you can follow the rules, and suggest that it is OK to
put id on any element, and use it as a fragment identifier in a
link, as given in the spec. Or you can be nice to your readers,
and workaround what is probably a display bug in some browsers.

In the case of this review, you were suggesting additional
"cleanup" on code that worked. Since there was no bug involved,
and thus no inherent need to

Re: [OpenJDK 2D-Dev] [10] Review Request: 8182410, 8183508, 8181289

2017-11-27 Thread Phil Race


The current changes get my "+1" as comformant HTML5.

-phil.

On 11/22/2017 07:58 PM, Jonathan Gibbons wrote:


Semyon,

You may indeed have explained why the behavior as it is, but we cannot 
and should not link this review with changes to the javadoc 
stylesheets, when the specific changes in the review are gratuitous 
and not necessary in the first place.


Yes, we may separately, and later, look at how the javadoc manages the 
header. Until then, I recommend that we stay within guidelines that 
are fully conformant HTML5, and without visual issues with the 
existing stylesheet.


So, I want to end this back and forth. I've spent enough time on this. 
I've given my review feedback, which remains to not introduce changes 
which may cause visual issues. If you and the AWT team want to proceed 
with those changes, I'm done.


-- Jon

On 11/22/17 7:46 PM, Semyon Sadetsky wrote:


Jon,

This is because you have fixed page header. For me it works equally 
in all browsers. I see no discrepancy between Chrome and Firefox on 
my Linux platform. I believe that the stylesheet.css you have in 
those examples does the magic :


a[name]:before, a[name]:target, a[id]:before, a[id]:target {
content: "";
display: inline-block;
position: relative;
padding-top: 129px;
margin-top: -129px;
}

so nothing specific comes from browser or "

I think the next link may help you

http://nicolasgallagher.com/jump-links-and-viewport-positioning/demo/

--Semyon


On 11/22/2017 02:53 PM, Jonathan Gibbons wrote:

Semyon,

I have reconstructed a very simple, very artificial example to demo 
the bug.   This example uses lots of filler text, but while that is 
artificial, for sake of recreating a demo,  note that the problem 
first appeared, for real, in real JDK 9 API documentation with 
extended doc comments, and that as a result, we followed the advice 
I have been trying to give you.


See the toy API bundle here:
http://cr.openjdk.java.net/~jjg/semyon/api/overview-summary.html

There are two modules, modA and modB.  Both have huge long doc 
comments, with a heading at the top and a link at the bottom.


In modA, the anchor is of the form .  In modB, the 
anchor is of the form .


In each of these files, scroll to the end of the comment, and look 
for a link, called "link", at the bottom of the page.  In both 
cases, the page scrolls so that the heading is near the top of the 
browser window, but in one case it is hidden under the javadoc 
navbar, and in the other case, it is clearly visible, below the 
javadoc navbar.


This is the difference in behavior that I can been trying to 
describe to you. I'm using Ubuntu 14.04 with Firefox 38, but I'm not 
the only one to have seen this effect.  I don't know whether you 
will get the same effect in your browser, but the fact that there is 
a reasonable OS/browser combo that demonstrates the problem is 
enough of a reason to avoid provoking the problem unnecessarily.   
If you don't see the problem on your browser, but want to see it in 
mine, I see you are in SCA22, so drop by my office for a demo.


I'll leave it to the AWT team to decide what to do about this 
bug/review. I still recommend updating what is necessary to fix 
issues, and not otherwise changing the doc comments unnecessarily, 
and not changing them in a way to provoke this bad behavior.


-- Jon




On 11/22/2017 12:10 PM, Semyon Sadetsky wrote:


Hi Jon,

This is not only about HTML5 spec, I also hardly can find resources 
that follow your "

You are correct that there is no bug here. But a bug was absent  
before this fix as well. This bug is about following to the HTML5 
standards, so let's follow them in full and not to return to this 
once again. We have a good chance to provide documentation in clean 
HTML5 after the fix without any workarounds.


--Semyon

On 11/14/2017 09:16 AM, Jonathan Gibbons wrote:


Semyon,

I read the HTML 5 spec the same as you, and we (on the Javadoc 
team) started using id on other elements, as well as  to 
provide a target that could be linked to.


However, the pragmatic experience was that the scrolling in some 
browsers did not completely reveal the element when there was a 
layered z component involved: the target element sometimes ended 
up under that layered component. Our experience was that the 
behavior was fixed when the target identifier was in an  element.


So, yes, you can follow the rules, and suggest that it is OK to 
put id on any element, and use it as a fragment identifier in a 
link, as given in the spec. Or you can be nice to your readers, 
and workaround what is probably a display bug in some browsers.


In the case of this review, you were suggesting additional 
"cleanup" on code that worked. Since there was no bug involved, 
and thus no inherent need to fix the code, my review feedback is 
to leave the code alone.  You may choose to insist differently, 
and I cannot say that what you are suggesting is against the spec; 
I can just say that we can

Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

2017-11-27 Thread Sergey Bylokhov


Hi, Shashi.

Also we should check what events are come to the application when this new API 
will be used. For example if 'm' will be pressed what notifications will be 
posted to the application?(keyTyped/keyPressed/keyReleased)


The test is still manual, I suggest to change it to automated and 
validate the behavior of "keyTyped/keyPressed/keyReleased". I suggest to 
implement it first and check that it works as expected on macOS and 
windows. After that we can take a look to the linux platform(For example 
I think KeyEvent.getExtendedKeyCodeForChar() should work on linux, and 
we can check can it be used in the proposed fix or not)


On 20/11/2017 21:03, Shashidhara Veerabhadraiah wrote:

Hi Sergey, Please find the code updates that you asked for. As discussed I have 
raised an exception for the linux platform as there is no equivalent functions 
being implemented yet.

Webrev: http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.04/

shashi

-Original Message-
From: Shashidhara Veerabhadraiah
Sent: Thursday, November 16, 2017 12:36 PM
To: Sergey Bylokhov ; Semyon Sadetsky 
; awt-dev@openjdk.java.net
Subject: Re:  [10] JDK-8148344: Java robot keypress should be able to 
use extended key code characters as ? ? ?.

Hi Sergey, Below are my replies:

shashi

-Original Message-
From: Sergey Bylokhov
Sent: Tuesday, November 14, 2017 3:32 AM
To: Shashidhara Veerabhadraiah ; Semyon 
Sadetsky ; awt-dev@openjdk.java.net
Subject: Re:  [10] JDK-8148344: Java robot keypress should be able to 
use extended key code characters as ? ? ?.

Hi, Shashi.
   115 @Override
   116 public void keyReleaseUnicode( int key ) {
   117 // No special functions that implements a unicode key press
   118 // and release in linux platform. Hence falls back to the
   119 // default ASCII key press/release functions.
   120 keyReleaseImpl(key);
   121 }

We should do something in this part of the fix, because we cannot use unicode 
point as a keyCode. It will produce incorrect result.
[Shashi] As discussed in the meeting, will add a unsupported exception in the 
following Webrev.

Also we should check what events are come to the application when this new API 
will be used. For example if 'm' will be pressed what notifications will be 
posted to the
application?(keyTyped/keyPressed/keyReleased)
[Shashi] It sends out the keyPressed/keyReleased events(WM_KEYUP/WM_KEYDOWN) 
events. The current code takes into account of the Unicode chars and uses the 
Unicode functions like ::ToUnicodeEx() to scan the characters.

On 05/11/2017 21:04, Shashidhara Veerabhadraiah wrote:

Hi Sergey, Please find the updated Webrev addressing your comments/requirements.

http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.03/

Thanks and regards,
Shashi

-Original Message-
From: Shashidhara Veerabhadraiah
Sent: Friday, October 27, 2017 6:44 PM
To: Sergey Bylokhov ; Semyon Sadetsky
; awt-dev@openjdk.java.net
Subject: Re:  [10] JDK-8148344: Java robot keypress should be able to 
use extended key code characters as ? ? ?.

Hi Sergey, below are my replies:

Thanks and regards,
shashi

-Original Message-
From: Sergey Bylokhov
Sent: Friday, October 27, 2017 11:47 AM
To: Shashidhara Veerabhadraiah
; Semyon Sadetsky
; awt-dev@openjdk.java.net
Subject: Re:  [10] JDK-8148344: Java robot keypress should be able to 
use extended key code characters as ? ? ?.

Hi, Shashi.
- Do we need to check passed unicode code-point in Robot.java using 
checkKeycodeArgument(key);?
[Shashi] I think yes. If the key value is zero I believe we don't need to 
process further.
- Can you please clarify how it will work on linux where we will use 
code-point as a keycode?
[Shashi] There is no update being done to the linux source code as I could not 
find native call which can interpret the Unicode. Hence it will behave same as 
the original keypress() and keyrelease().
- It would be good if the names of the parameters will be 
unified/corrected, for example:
private native void keyEventUnicode(int javaKeyCode, boolean keydown); 
"javaKeyCode" - Is it a java key code or a Unicode code-point?
[Shashi] Sure will update in the coming pass.

Why the test is manual? Isn't an application should  recognize this new 
functionality automatically? Additionally it would be good to test all key 
related listeners(keyTyped/keyPressed/keyReleased).
[Shashi] We need to be sure that the Unicode key indeed displayed as the 
standard Unicode. There is no other way to confirm that it is indeed been the 
same standard Unicode that's been displayed.

Debug code in awt_Robot.cpp
if(isUnicode) {printf("In unicode func:%d", jkey); [Shashi] Sure will update in 
the coming pass.


Also I would like to propose an idea for discussion: probably it would be 
better to create only one Robot#type(codePoint) method? What do you think?
[Shashi] It can be done but the only problem is that it is kinda different from 
the keypress() and ke

Re: [8u] RFR: JDK8U Backport of 8183504: 8u131 Win 10, issue with wrong position of Sogou IME popup

2017-11-27 Thread Prasanta Sadhukhan


+1

Regards
Prasanta
On 11/27/2017 5:13 PM, Sreeprakash Sreedharan wrote:


Thanks for your review Prasanta. I have updated the webrev with the 
change.


Updated Webrev : 
http://cr.openjdk.java.net/~ssreedharan/8183504/jdk8u-dev/webrev.01/ 



Regards,

Sreeprakash

*From:*Prasanta Sadhukhan
*Sent:* Monday, November 27, 2017 4:09 PM
*To:* Sreeprakash Sreedharan ; Semyon 
Sadetsky 

*Cc:* awt-dev@openjdk.java.net
*Subject:* Re: [8u] RFR: JDK8U Backport of 8183504: 8u131 Win 10, 
issue with wrong position of Sogou IME popup


You need to set "cfr" here

3877 cf.rcArea.left = cf.rcArea.top = cf.rcArea.right = 
cf.rcArea.bottom = 0;


Regards
Prasanta

On 11/27/2017 2:56 PM, Sreeprakash Sreedharan wrote:

Hi,

Please review this webrev for JDK-8u backport.

Webrev:
http://cr.openjdk.java.net/~ssreedharan/8183504/jdk8u-dev/webrev.00/



Main Bug: https://bugs.openjdk.java.net/browse/JDK-8183504

JDK10 review thread:
http://mail.openjdk.java.net/pipermail/awt-dev/2017-October/013155.html


JDK10 changeset: http://hg.openjdk.java.net/jdk/jdk/rev/fd3c961a89ec

The patch from JDK10 was not applied cleanly.

Changed,

cf.ptCurrentPos = {x, y};

cf.rcArea = {0, 0, 0, 0};

to

cf.ptCurrentPos.x = x;

cf.ptCurrentPos.y = y;

cf.rcArea.left = cf.rcArea.top = cf.rcArea.right =
cf.rcArea.bottom = 0;

in two places.

CANDIDATEFORM ptCurrentPos and rcArea were assigned through
copy-list-initialization which is a C++ 11 feature.

This was giving compiler error for JDK8.

Regards,

Sreeprakash

Re: [8u] RFR: JDK8U Backport of 8183504: 8u131 Win 10, issue with wrong position of Sogou IME popup

2017-11-27 Thread Sreeprakash Sreedharan

Thanks for your review Prasanta. I have updated the webrev with the change.

 

Updated Webrev : 
http://cr.openjdk.java.net/~ssreedharan/8183504/jdk8u-dev/webrev.01/ 

 

Regards,

Sreeprakash

 

From: Prasanta Sadhukhan 
Sent: Monday, November 27, 2017 4:09 PM
To: Sreeprakash Sreedharan ; Semyon Sadetsky 

Cc: awt-dev@openjdk.java.net
Subject: Re: [8u] RFR: JDK8U Backport of 8183504: 8u131 Win 10, issue with 
wrong position of Sogou IME popup

 

You need to set "cfr" here

3877 cf.rcArea.left = cf.rcArea.top = cf.rcArea.right = 
cf.rcArea.bottom = 0;

Regards
Prasanta

On 11/27/2017 2:56 PM, Sreeprakash Sreedharan wrote:

Hi,

 

Please review this webrev for JDK-8u backport.

Webrev: HYPERLINK 
"http://cr.openjdk.java.net/%7Essreedharan/8183504/jdk8u-dev/webrev.00/"http://cr.openjdk.java.net/~ssreedharan/8183504/jdk8u-dev/webrev.00/
 

 

Main Bug: https://bugs.openjdk.java.net/browse/JDK-8183504 

JDK10 review thread: 
http://mail.openjdk.java.net/pipermail/awt-dev/2017-October/013155.html 

JDK10 changeset: http://hg.openjdk.java.net/jdk/jdk/rev/fd3c961a89ec 

 

The patch from JDK10 was not applied cleanly.

 

Changed,

 

cf.ptCurrentPos = {x, y};

cf.rcArea = {0, 0, 0, 0};

 

to

 

cf.ptCurrentPos.x = x;

cf.ptCurrentPos.y = y;

cf.rcArea.left = cf.rcArea.top = cf.rcArea.right = cf.rcArea.bottom = 0;

 

in two places.

 

CANDIDATEFORM ptCurrentPos and rcArea were assigned through 
copy-list-initialization which is a C++ 11 feature.

This was giving compiler error for JDK8.

 

Regards,

Sreeprakash

Re: [10] Review request for JDK-8158366: [macosx] Regression: closed/java/awt/dnd/RecognizedActionTest/RecognizedActionTest.html fails

2017-11-27 Thread Manajit Halder

Hi Ajit,

Modified the code as per your review comments.
Please review the changes.

http://cr.openjdk.java.net/~mhalder/8158366/webrev.01/ 


Thanks,
Manajit

> On 27-Nov-2017, at 1:50 PM, Ajit Ghaisas  wrote:
> 
> 1) This test lacks copyright banner at the top
> 2) init() prints to System.err & returns silently in case of failure - 
> suggest to capture failure and throw exception.
> 
> Regards,
> Ajit
> 
> -Original Message-
> From: Prem Balakrishnan 
> Sent: Monday, November 27, 2017 12:02 PM
> To: Sergey Bylokhov; Manajit Halder
> Cc: awt-dev@openjdk.java.net
> Subject: Re:  [10] Review request for JDK-8158366: [macosx] 
> Regression: 
> closed/java/awt/dnd/RecognizedActionTest/RecognizedActionTest.html fails
> 
> +1
> 
> Regards,
> Prem
> 
> -Original Message-
> From: Sergey Bylokhov 
> Sent: Friday, November 24, 2017 1:16 PM
> To: Manajit Halder ; Prem Balakrishnan 
> 
> Cc: awt-dev@openjdk.java.net
> Subject: Re: [10] Review request for JDK-8158366: [macosx] 
> Regression: 
> closed/java/awt/dnd/RecognizedActionTest/RecognizedActionTest.html fails
> 
> Looks fine.
> 
> On 23/11/2017 02:05, Manajit Halder wrote:
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8158366
>> Webrev:
>> http://cr.openjdk.java.net/~mhalder/8158366/webrev.00/
> 
> 
> 
> -- 
> Best regards, Sergey.

Re: [8u] RFR: JDK8U Backport of 8183504: 8u131 Win 10, issue with wrong position of Sogou IME popup

2017-11-27 Thread Prasanta Sadhukhan


You need to set "cfr" here

3877 cf.rcArea.left = cf.rcArea.top = cf.rcArea.right = cf.rcArea.bottom 
= 0;


Regards
Prasanta
On 11/27/2017 2:56 PM, Sreeprakash Sreedharan wrote:


Hi,

Please review this webrev for JDK-8u backport.

Webrev: 
http://cr.openjdk.java.net/~ssreedharan/8183504/jdk8u-dev/webrev.00/ 



Main Bug: https://bugs.openjdk.java.net/browse/JDK-8183504

JDK10 review thread: 
http://mail.openjdk.java.net/pipermail/awt-dev/2017-October/013155.html


JDK10 changeset: http://hg.openjdk.java.net/jdk/jdk/rev/fd3c961a89ec

The patch from JDK10 was not applied cleanly.

Changed,

cf.ptCurrentPos = {x, y};

cf.rcArea = {0, 0, 0, 0};

to

cf.ptCurrentPos.x = x;

cf.ptCurrentPos.y = y;

cf.rcArea.left = cf.rcArea.top = cf.rcArea.right = cf.rcArea.bottom = 0;

in two places.

CANDIDATEFORM ptCurrentPos and rcArea were assigned through 
copy-list-initialization which is a C++ 11 feature.


This was giving compiler error for JDK8.

Regards,

Sreeprakash

[8u] RFR: JDK8U Backport of 8183504: 8u131 Win 10, issue with wrong position of Sogou IME popup

2017-11-27 Thread Sreeprakash Sreedharan

Hi,

 

Please review this webrev for JDK-8u backport.

Webrev: http://cr.openjdk.java.net/~ssreedharan/8183504/jdk8u-dev/webrev.00/ 

 

Main Bug: https://bugs.openjdk.java.net/browse/JDK-8183504 

JDK10 review thread: 
http://mail.openjdk.java.net/pipermail/awt-dev/2017-October/013155.html 

JDK10 changeset: http://hg.openjdk.java.net/jdk/jdk/rev/fd3c961a89ec 

 

The patch from JDK10 was not applied cleanly.

 

Changed,

 

cf.ptCurrentPos = {x, y};

cf.rcArea = {0, 0, 0, 0};

 

to

 

cf.ptCurrentPos.x = x;

cf.ptCurrentPos.y = y;

cf.rcArea.left = cf.rcArea.top = cf.rcArea.right = cf.rcArea.bottom = 0;

 

in two places.

 

CANDIDATEFORM ptCurrentPos and rcArea were assigned through 
copy-list-initialization which is a C++ 11 feature.

This was giving compiler error for JDK8.

 

Regards,

Sreeprakash

Re: [10] Review request for JDK-8158366: [macosx] Regression: closed/java/awt/dnd/RecognizedActionTest/RecognizedActionTest.html fails

2017-11-27 Thread Ajit Ghaisas

1) This test lacks copyright banner at the top
2) init() prints to System.err & returns silently in case of failure - suggest 
to capture failure and throw exception.

Regards,
Ajit

-Original Message-
From: Prem Balakrishnan 
Sent: Monday, November 27, 2017 12:02 PM
To: Sergey Bylokhov; Manajit Halder
Cc: awt-dev@openjdk.java.net
Subject: Re:  [10] Review request for JDK-8158366: [macosx] 
Regression: closed/java/awt/dnd/RecognizedActionTest/RecognizedActionTest.html 
fails

+1

Regards,
Prem

-Original Message-
From: Sergey Bylokhov 
Sent: Friday, November 24, 2017 1:16 PM
To: Manajit Halder ; Prem Balakrishnan 

Cc: awt-dev@openjdk.java.net
Subject: Re: [10] Review request for JDK-8158366: [macosx] Regression: 
closed/java/awt/dnd/RecognizedActionTest/RecognizedActionTest.html fails

Looks fine.

On 23/11/2017 02:05, Manajit Halder wrote:
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8158366
> Webrev:
> http://cr.openjdk.java.net/~mhalder/8158366/webrev.00/



-- 
Best regards, Sergey.

Re: [10] JDK-8146537: TrayIcon Action Listener doesnt work in WIndows 10

Re: [10] Review request for JDK-8158366: [macosx] Regression: closed/java/awt/dnd/RecognizedActionTest/RecognizedActionTest.html fails

Re: [OpenJDK 2D-Dev] [10] Review Request: 8182410, 8183508, 8181289

Re: [OpenJDK 2D-Dev] [10] Review Request: 8182410, 8183508, 8181289

Re: [OpenJDK 2D-Dev] [10] Review Request: 8182410, 8183508, 8181289

Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

Re: [8u] RFR: JDK8U Backport of 8183504: 8u131 Win 10, issue with wrong position of Sogou IME popup

Re: [8u] RFR: JDK8U Backport of 8183504: 8u131 Win 10, issue with wrong position of Sogou IME popup

Re: [10] Review request for JDK-8158366: [macosx] Regression: closed/java/awt/dnd/RecognizedActionTest/RecognizedActionTest.html fails

Re: [8u] RFR: JDK8U Backport of 8183504: 8u131 Win 10, issue with wrong position of Sogou IME popup

[8u] RFR: JDK8U Backport of 8183504: 8u131 Win 10, issue with wrong position of Sogou IME popup

Re: [10] Review request for JDK-8158366: [macosx] Regression: closed/java/awt/dnd/RecognizedActionTest/RecognizedActionTest.html fails

12 matches

Site Navigation

Mail list logo

Footer information