Re: RFR: JDK-8165232 XKeycodeToKeysym is deprecated and should be replaced with XkbKeycodeToKeysym

On 06/10/2016 19:38, Phil Race wrote: PS I am going to change the bug synopsis since otherwise we'll be committing to the mercurial history something which is different than what we actually did. I'll just truncate it to "XKeycodeToKeysym is deprecated and should be replaced" Oh .. Alan see

Re: RFR: JDK-8165232 XKeycodeToKeysym is deprecated and should be replaced with XkbKeycodeToKeysym

On 06/10/2016 19:32, Phil Race wrote: .. and Alan I did suggest last time that the updated webrev be a ".1" as in place replacement loses history and context for people who aren't reading the email thread "live". Oops, sorry you did say that and I forgot this time round - apologies. -- Alan

Re: RFR: JDK-8165232 XKeycodeToKeysym is deprecated and should be replaced with XkbKeycodeToKeysym

PS I am going to change the bug synopsis since otherwise we'll be committing to the mercurial history something which is different than what we actually did. I'll just truncate it to "XKeycodeToKeysym is deprecated and should be replaced" Oh .. Alan see you already did exactly that :-). So we

Re: RFR: JDK-8165232 XKeycodeToKeysym is deprecated and should be replaced with XkbKeycodeToKeysym

+1 .. and Alan I did suggest last time that the updated webrev be a ".1" as in place replacement loses history and context for people who aren't reading the email thread "live". I'll push this for Alan since I think he asked for that help .. -phil. On 10/06/2016 11:21 AM, Alexander

Re: RFR: JDK-8165232 XKeycodeToKeysym is deprecated and should be replaced with XkbKeycodeToKeysym

+1 P.S. It wasn't hard to find, but the webrev is updated at the first revision http://cr.openjdk.java.net/~alanbur/JDK-8165232 -- Thanks, Alexander. On 06.10.2016 13:18, Alan Burlison wrote: On 04/10/2016 19:34, Alan Burlison wrote: key_syms is not freed. So there is, thanks for the

Re: 8167126: Create a module to provide access to non-SE desktop APIs

On 06/10/2016 17:28, Phil Race wrote: OK .. so long as there's no --add-modules needed for that. Seems to work. Updated webrev :- http://cr.openjdk.java.net/~prr/8167126.1/ No --add-modules. The updated webrev looks okay to me. -Alan

Re: [8u-dev] Review request for 8166591 [macos 10.12] Trackpad scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)

Looks fine. On 05.10.16 23:10, Alexandr Scherbatiy wrote: Just corrected the subject to 8u-dev. Thanks, Alexandr. 05.10.2016 22:46, Alexandr Scherbatiy пишет: Hello, Could you review the backport of the fix to the JDK8u-dev:

Re: 8167126: Create a module to provide access to non-SE desktop APIs

OK .. so long as there's no --add-modules needed for that. Seems to work. Updated webrev :- http://cr.openjdk.java.net/~prr/8167126.1/ -phil. On 10/06/2016 09:04 AM, Alan Bateman wrote: On 06/10/2016 16:58, Phil Race wrote: Similar modules were on the BOOT list. Can you explain what each of

Re: 8167126: Create a module to provide access to non-SE desktop APIs

On 06/10/2016 16:58, Phil Race wrote: Similar modules were on the BOOT list. Can you explain what each of these lists are and the implications of being (and not being) listed on each of them ? -phil. The BOOT_MODULES list is the list of modules defined to the boot loader, the PLATFORM_MODULES

Re: 8167126: Create a module to provide access to non-SE desktop APIs

Similar modules were on the BOOT list. Can you explain what each of these lists are and the implications of being (and not being) listed on each of them ? -phil. On 10/06/2016 12:24 AM, Alan Bateman wrote: On 05/10/2016 23:01, Phil Race wrote: Webrev :

Re: [9] Review request for 8166594: Taskbar.setWindowProgressValue() spec does not specify expected visual behavior of setWindowProgressValue()

On 10/6/2016 3:38 PM, Alexander Zvegintsev wrote: Hi Semyon, Yes it is, Microsoft defined some set of rules for such case[0]. However it looks redundant and too implementation-specific(which can be changed) for me. I didn't mean to specify the behavior for Windows platform. It seems that

Re: [9] Review request for 8166594: Taskbar.setWindowProgressValue() spec does not specify expected visual behavior of setWindowProgressValue()

Hi Semyon, Yes it is, Microsoft defined some set of rules for such case[0]. However it looks redundant and too implementation-specific(which can be changed) for me. Reformatted for 80 chars in place. [0]

Re: [9] Review request for 8166942: Usage of SplashScreen Functions hangs up FX Application

You are right, it it undefined behavior. On 10/6/16 10:02 AM, Semyon Sadetsky wrote: Hi Alexander, Is it safe to lock the mutex on one thread and unlock it on another? --Semyon On 06.10.2016 06:08, Alexander Zvegintsev wrote: Hello, please review the fix

Re: [9] Review request for JDK-8165555: [macosx] VM crashes on second attempt to execute JCK interactive tests that use Robot (single JVM, agent)

Looks good to me. > On 06-Oct-2016, at 4:20 pm, Sergey Bylokhov > wrote: > > Looks fine. > > On 05.10.16 12:57, Manajit Halder wrote: >> Hi Sergey, >> >> Thanks for the comments. Please review the updated webrev. >>

Review Request JDK:-8162959 [HiDPI] screenshot artifacts using AWT Robot

Hi, Please review fix for JDK 9, Bug: https://bugs.openjdk.java.net/browse/JDK-8162959 Webrev: http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.00/ I have adapted the same fix as used for JavaFX Robot Bug: HYPERLINK

Re: [9] Review request for JDK-8165555: [macosx] VM crashes on second attempt to execute JCK interactive tests that use Robot (single JVM, agent)

Looks fine. On 05.10.16 12:57, Manajit Halder wrote: Hi Sergey, Thanks for the comments. Please review the updated webrev. http://cr.openjdk.java.net/~mhalder/816/webrev.04/ The “frame” can’t be a local variable as it is used in two different threads inside the function. Thanks, Manajit

Re: RFR: JDK-8165232 XKeycodeToKeysym is deprecated and should be replaced with XkbKeycodeToKeysym

On 04/10/2016 19:34, Alan Burlison wrote: key_syms is not freed. So there is, thanks for the catch. Done, webrev updated, jprt -tset hostpot rerun & clean. -- Alan Burlison --

Re: 8167126: Create a module to provide access to non-SE desktop APIs

On 05/10/2016 23:01, Phil Race wrote: Webrev : http://cr.openjdk.java.net/~prr/8167126/ The upcoming jigsaw changes to limit use of setAccessible [1] mean that some work-arounds for non-SE API users will be broken. To provide for continued access to the capability (albeit via a different

Re: [9] Review request for 8166942: Usage of SplashScreen Functions hangs up FX Application

Hi Alexander, Is it safe to lock the mutex on one thread and unlock it on another? --Semyon On 06.10.2016 06:08, Alexander Zvegintsev wrote: Hello, please review the fix http://cr.openjdk.java.net/~azvegint/jdk/9/8166942/00/ for the issue https://bugs.openjdk.java.net/browse/JDK-8166942

Re: [9] Review request for 8166594: Taskbar.setWindowProgressValue() spec does not specify expected visual behavior of setWindowProgressValue()

Hi Alexander, 416 * Note that the behavior is undefined when multiple windows is grouped in the task area. Isn't the above a some kind of simplification? Could you reformat changed lines to make them following the 80 chars maximum? --Semyon On 06.10.2016 04:56, Alexander Zvegintsev