Re: RFR: 8271396: Spelling errors

On Wed, 28 Jul 2021 17:08:01 GMT, Emmanuel Bourg wrote: >> I'm happy to sponsor this change, but could you please update the copyright >> year where necessary, e.g. in >> src/java.desktop/unix/classes/sun/awt/X11/XMSelection.java: >> `Copyright (c) 2003, 2018, Oracle...` -> `Copyright (c)

Re: [jdk17] RFR: 8269984: [macos] JTabbedPane title looks like disabled [v2]

On Fri, 23 Jul 2021 05:49:25 GMT, Alexander Zuev wrote: >> Fixed the version string parsing to work correctly on macOS 11.x and beyond > > Alexander Zuev has updated the pull request incrementally with one additional > commit since the last revision: > > Demoved isBigSurOrAbove variable that

Re: [jdk17] RFR: 8269984: [macos] JTabbedPane title looks like disabled

On Thu, 22 Jul 2021 16:25:40 GMT, Alexander Zuev wrote: > Fixed the version string parsing to work correctly on macOS 11.x and beyond Looks good. I also tested it on macOS 11.5 and verified that the test case fails (is rendered incorrectly) without your fix and passes with your fix. @prsadhuk

Re: RFR: 8270859: Post JEP 411 refactoring: client libs with maximum covering > 10K

On Fri, 16 Jul 2021 21:39:56 GMT, Vest wrote: >> This is the last part of Post JEP 411 refactoring that makes >> `@SuppressWarnings("removal")` more fine grained. This fix deals with all >> client libs annotations that cover more than 10K bytes of code. > >

Re: RFR: 8256465: [macos] Java frame and dialog presented full screen freeze application [v11]

On Fri, 4 Jun 2021 14:25:31 GMT, Tejpal Rebari wrote: >> Hi All, >> Please review the following fix for jdk17. >> >> Issue : On MacOS 11 Java Frame and JDialog application is freezing in Full >> Screen when the System Preference -> General -> Prefer Tabs is set to "Full >> Screen". It is

Re: RFR: 8256465: [macos] Java frame and dialog presented full screen freeze application [v10]

On Thu, 3 Jun 2021 16:55:12 GMT, Tejpal Rebari wrote: >> Hi All, >> Please review the following fix for jdk17. >> >> Issue : On MacOS 11 Java Frame and JDialog application is freezing in Full >> Screen when the System Preference -> General -> Prefer Tabs is set to "Full >> Screen". It is

Re: RFR: 8256465: [macos11] Java frame and dialog presented full screen freeze application [v8]

On Mon, 31 May 2021 14:05:51 GMT, Tejpal Rebari wrote: >> Hi All, >> Please review the following fix for jdk17. >> >> Issue : On MacOS 11 Java Frame and JDialog application is freezing in Full >> Screen when the System Preference -> General -> Prefer Tabs is set to "Full >> Screen". It is

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3]

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP >> 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. >>

Re: RFR: 8256465: [macos11] Java frame and dialog presented full screen freeze application [v3]

On Thu, 13 May 2021 20:46:28 GMT, Phil Race wrote: >> Tejpal Rebari has updated the pull request incrementally with one additional >> commit since the last revision: >> >> code cleanup > > src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m line 1106: > >> 1104: { >> 1105:

Re: RFR: 8256465: [macos11] Java frame and dialog presented full screen freeze application

On Sat, 10 Apr 2021 23:22:06 GMT, Philip Race wrote: > The system dialog UI talks of "documents" which might tell us something about > the mindset of the folks who designed it. Yes, that was my thinking. This seems like a setting meant for applications whose windows are a set of "documents",

Re: RFR: 8256465: [macos11] Java frame and dialog presented full screen freeze application

On Sat, 10 Apr 2021 23:22:06 GMT, Philip Race wrote: > The system dialog UI talks of "documents" which might tell us something about > the mindset of the folks who designed it. Yes, that was my thinking. This seems like a setting meant for applications whose windows are a set of "documents",

Re: RFR: 8256465: [macos11] Java frame and dialog presented full screen freeze application

On Sat, 10 Apr 2021 23:22:06 GMT, Philip Race wrote: > The system dialog UI talks of "documents" which might tell us something about > the mindset of the folks who designed it. Yes, that was my thinking. This seems like a setting meant for applications whose windows are a set of "documents",

Re: RFR: 8256465: [macos11] Java frame and dialog presented full screen freeze application

On Fri, 9 Apr 2021 22:39:18 GMT, Sergey Bylokhov wrote: >> Without this fix, owned windows will open in a new window and new top level >> windows will open in a tab. As I discovered when evaluating >> [JDK-8263169](https://bugs.openjdk.java.net/browse/JDK-8263169), which >> @trebari referred

Re: RFR: 8256465: [macos11] Java frame and dialog presented full screen freeze application

On Fri, 9 Apr 2021 20:42:26 GMT, Kevin Rushforth wrote: >>> > Fix is to set allowsAutomaticWindowTabbing to No for all the MacOS >>> > release staring from 10.12. >>> > The allowsAutomaticTabbing was introduced in MacOS 10.12 but the default >>>

Re: RFR: 8256465: [macos11] Java frame and dialog presented full screen freeze application

On Fri, 9 Apr 2021 05:42:37 GMT, Tejpal Rebari wrote: > Hi All, > Please review the following fix for jdk17. > > Issue : On MacOS 11 Java Frame and JDialog application is freezing in Full > Screen when the System Preference -> General -> Prefer Tabs is set to "Full > Screen". It is also

Re: RFR: 8256465: [macos11] Java frame and dialog presented full screen freeze application

On Fri, 9 Apr 2021 07:21:55 GMT, Tejpal Rebari wrote: >>> Fix is to set allowsAutomaticWindowTabbing to No for all the MacOS release >>> staring from 10.12. >>> The allowsAutomaticTabbing was introduced in MacOS 10.12 but the default >>> value changed in macos11. >> >> But why the option

Re: RFR: 8258788: incorrect response to change in window insets [lanai] [v2]

On Fri, 2 Apr 2021 11:44:52 GMT, Alexey Ushakov wrote: >> Dynamically change MTLLayer insets depending on FULL_WINDOW_CONTENT >> property. MTLLayer.h header cleanup. > > Alexey Ushakov has updated the pull request incrementally with one additional > commit since the last revision: > >

Re: RFR: 8189198: Add "forRemoval = true" to Applet API deprecations [v2]

On Thu, 25 Mar 2021 22:58:53 GMT, Andy Herrick wrote: >> implementation of >> JDK-8256145: JEP 398: Deprecate the Applet API for Removal > > Andy Herrick has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes >

Re: RFR: 8189198: Add "forRemoval = true" to Applet API deprecations

On Wed, 10 Mar 2021 18:33:37 GMT, Andy Herrick wrote: > implementation of > JDK-8256145: JEP 398: Deprecate the Applet API for Removal src/java.desktop/share/classes/java/applet/package-info.java line 39: > 37: * applet development environment. > 38: * > 39: * @deprecated. This package

Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v13]

On Thu, 11 Mar 2021 18:00:15 GMT, Ajit Ghaisas wrote: >> **Description :** >> This is the implementation of [JEP 382 : New macOS Rendering >> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361) >> It implements a Java 2D internal rendering pipeline for macOS using the >> Apple Metal

Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v12]

On Wed, 10 Mar 2021 10:51:08 GMT, Ajit Ghaisas wrote: >> **Description :** >> This is the implementation of [JEP 382 : New macOS Rendering >> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361) >> It implements a Java 2D internal rendering pipeline for macOS using the >> Apple Metal

Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v3]

On Mon, 8 Feb 2021 17:15:25 GMT, Gerard Ziemski wrote: > General comment - I am not sure I like the `MTL` prefix acronym in names (ex. > `sun.java2d.metal.MTLVolatileSurfaceManager`). > > I think you tried to match the `CGL`, but that is a real acronym that stands > for "Core Graphics Layer"

Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v3]

On Mon, 8 Feb 2021 13:40:22 GMT, Ajit Ghaisas wrote: >> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 894: >> >>> 892: SHADERS_SUPPORT_DIR := >>> $(SUPPORT_OUTPUTDIR)/native/java.desktop/libosxui >>> 893: SHADERS_AIR := $(SHADERS_SUPPORT_DIR)/shaders.air >>> 894: SHADERS_LIB :=

Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline

On Thu, 4 Feb 2021 10:35:02 GMT, Ajit Ghaisas wrote: > **Description :** > This is the implementation of [JEP 382 : New macOS Rendering > Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361) > It implements a Java 2D internal rendering pipeline for macOS using the Apple > Metal API. >

Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline

On Thu, 4 Feb 2021 10:35:02 GMT, Ajit Ghaisas wrote: > **Description :** > This is the implementation of [JEP 382 : New macOS Rendering > Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361) > It implements a Java 2D internal rendering pipeline for macOS using the Apple > Metal API. >

Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline

On Thu, 4 Feb 2021 10:35:02 GMT, Ajit Ghaisas wrote: > **Description :** > This is the implementation of [JEP 382 : New macOS Rendering > Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361) > It implements a Java 2D internal rendering pipeline for macOS using the Apple > Metal API. >

Re: RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module [v2]

On Mon, 1 Feb 2021 18:33:32 GMT, Gerard Ziemski wrote: >> Marked as reviewed by gziemski (Committer). > > The changes look good to me, but please see my comment from my review about > documenting `NormalizedPathNSStringFromJavaString()` API. The following commit was integrated to jdk master

Re: RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module [v3]

On Tue, 2 Feb 2021 00:30:07 GMT, Phil Race wrote: >> src/java.desktop/macosx/native/libosxapp/ThreadUtilities.m line 53: >> >>> 51: @implementation ThreadUtilities >>> 52: >>> 53: + (void)initialize { >> >> I think we need to check how this new modes will work when the AWT is >> embedded

Re: [jdk16] RFR: 8245922: [macos] Taskbar.Feature.ICON_BADGE_NUMBER no longer supported on MacOS

On Wed, 23 Dec 2020 01:11:50 GMT, Sergey Bylokhov wrote: > This is rollback of the fix for > https://bugs.openjdk.java.net/browse/JDK-8230869 > That functionality was disabled due to the bug in the macOS Catalina, that > bug was fixed so we can reenable the ICON_BADGE_NUMBER feature. I can

Re: RFR: 8254850: Update terminology in java.awt.GridBagLayout source code comments

On Tue, 15 Dec 2020 17:47:54 GMT, Phil Race wrote: > This is part of an effort in the JDK to replace archaic/non-inclusive words > with more neutral terms. > See JDK-8253315 for details. > > This updates a few comments in GridBagLayout to use the terms parent and > child which are >

Re: RFR: 8252015: [macos11] java.awt.TrayIcon requires updates for template images

On Fri, 4 Dec 2020 14:59:05 GMT, Peter Zhelezniakov wrote: >> Please check the tests in the .../test/jdk/java/awt/TrayIcon/ folder it >> looks like some of them fail after the fix: >> java/awt/TrayIcon/ActionCommand/ActionCommand.java >> java/awt/TrayIcon/ActionEventMask/ActionEventMask.java

Re: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v3]

On Fri, 13 Nov 2020 15:05:15 GMT, Andy Herrick wrote: >> JDK-8189198: Add "forRemoval = true" to Applet APIs > > Andy Herrick has updated the pull request incrementally with one additional > commit since the last revision: > > JDK-8189198: Add "forRemoval = true" to Applet APIs

Re: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v2]

On Fri, 13 Nov 2020 09:31:53 GMT, Alan Bateman wrote: >> Andy Herrick has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains six additional >> commits

Re: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs

On Mon, 9 Nov 2020 13:56:33 GMT, Andy Herrick wrote: > JDK-8189198: Add "forRemoval = true" to Applet APIs @andyherrick can you enter the `/csr needed` command? I would, but it needs to be done by either the author of the PR or a Reviewer. - PR:

Re: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs

On Mon, 9 Nov 2020 13:57:32 GMT, Andy Herrick wrote: >> JDK-8189198: Add "forRemoval = true" to Applet APIs > > preliminary changes for JDK-8189198 for evaluation The following field, which is currently deprecated (not for removal) should probably also be marked as deprecated for removal::

Re: RFR: 8251854: [macosx] Java forces the use of discrete GPU

On Tue, 10 Nov 2020 13:24:21 GMT, Erik Joelsson wrote: >> This is a review request for the bug particularly fixed some time ago: >> https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html >> >> In that review request it was found that the old fix does not work well in >> all cases,

Re: RFR: 8251854: [macosx] Java forces the use of discrete GPU

On Tue, 10 Nov 2020 08:19:13 GMT, Sergey Bylokhov wrote: > This is a review request for the bug particularly fixed some time ago: > https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html > > In that review request it was found that the old fix does not work well in > all cases,

Re: RFR: JDK-8253791: Issue with useAppleColor check in CSystemColors.m

On Tue, 29 Sep 2020 15:30:00 GMT, Paul Hohensee wrote: >> While looking into XCode 12 compilation issues, a problem in >> jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m was >> found when checking the useAppleColor flag . >> Because this is a general issue and not really

Re: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase

On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote: >> The code in java.base was updated to use String::isEmpty in JDK 12 >> (JDK-8215281). There was follow-up in JDK 13 to do >> the same in the java.desktop module (JDK-8223237). Changing the remaining >> usages make sense although I see

Re: RFR: 8252999: replace all String.equals("") usages with String.isEmpty()

On Wed, 9 Sep 2020 07:57:48 GMT, Dmitriy Dumanskiy wrote: >> @doom369 jcheck requires an associated issue > > @mrserb hello. Thanks for the review. Any further actions required from me? Before this Enhancement can be formally reviewed, you will need a JBS bug ID. If you are already working

Re: [OpenJDK 2D-Dev] RFR: 8240487 : Cleanup whitespace in .cc, .hh, .m, and .mm files

Looks good to me. I verified that the only changes are whitespace changes, and that after applying the patch there are no more whitespace errors. +1 -- Kevin On 8/5/2020 6:46 PM, Philip Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8240487 Webrev:

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

es with patch. AlphaPrintTest shows instructions without patch also. @Phil : I think its better if we test at uiScale=1(larger memory footprint). Please clarify. Thanks, Jay On 11-Jun-2020, at 5:53 PM, Kevin Rushforth mailto:kevin.rushfo...@oracle.com>> wrote: Do you have a Hi-DPI mac

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

1-Jun-2020, at 5:53 PM, Kevin Rushforth mailto:kevin.rushfo...@oracle.com>> wrote: Do you have a Hi-DPI machine? I do, and had to run with "-Dsun.java2d.uiScale=1" in order to see the failure with LargeWindowPaintTest. For AlphaPrintTest, the test deliberately ensures that

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

Do you have a Hi-DPI machine? I do, and had to run with "-Dsun.java2d.uiScale=1" in order to see the failure with LargeWindowPaintTest. For AlphaPrintTest, the test deliberately ensures that you print before saying whether it passes or not. FWIW, I verified that the printing test on my

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

+1 Code changes look good. I verified that the bug happens on my Windows 10 laptop with SwingSet2 and with the LargeWindowPaintTest without the patch, and everything looks good with the patch. -- Kevin On 6/10/2020 1:48 PM, Philip Race wrote: Bug:

Re: [14] Review Request: 8236953 [macos] JavaFX SwingNode is not rendered on macOS

Looks good to me. I tested it on my Mac with a few SwingNode apps, and they all render correctly with the fix applied. +1 -- Kevin On 1/14/2020 8:10 PM, Sergey Bylokhov wrote: Hello. Please review the fix for JDK 14. Bug: https://bugs.openjdk.java.net/browse/JDK-8236953 Fix:

Re: [13] Review Request: 8217676 Upgrade libpng to 1.6.37

Looks fine to me, too. +1 On 7/29/2019 4:56 PM, Philip Race wrote: OK +1 assuming you ran the small set of PNG SplashScreen tests we have .. -phil. On 7/29/19, 3:51 PM, Sergey Bylokhov wrote: The fix is updated: http://cr.openjdk.java.net/~serb/8217676/webrev.01 On 29.07.2019 13:10, Phil

Re: [13] Review Request: 8217676 Upgrade libpng to 1.6.37

Looks good to me. -- Kevin On 7/25/2019 5:55 PM, Sergey Bylokhov wrote: Hello. Please review the fix for JDK 13. Bug: https://bugs.openjdk.java.net/browse/JDK-8217676 Fix: http://cr.openjdk.java.net/~serb/8217676/webrev.00 This is an upgrade of the libpng library to the latest version. Most

[14] RFR: 8222563: Remove terminally deprecated method netscape.javascript.JSObject::getWindow

Please review the webrev [1] for JDK-8222563 [2] to remove the terminally deprecated netscape.javascript.JSObject::getWindow method. The proposed fix also eliminates the dependency from the jdk.jsobject module on the java.desktop module. The fix removes the

Re: RFR: 8225487: giflib legal file is missing attribution for openbsd-reallocarray.c

Looks good (but I'm not a "R"eviewer). -- Kevin On 6/7/2019 2:15 PM, Phil Race wrote: bug : https://bugs.openjdk.java.net/browse/JDK-8225487 webrev :  http://cr.openjdk.java.net/~prr/8225487/ A 2016 update to giflib brought in a new source file openbsd-reallocarray.c We need attribution

Re: [12] Review Request: JDK-8215364: JavaFX crashes on Ubuntu 18.04 with Wayland while using Swing-FX interop

+1 -- Kevin On 12/20/2018 11:03 AM, Phil Race wrote: +1 -phil. On 12/14/18 5:48 AM, Pankaj Bansal wrote: Hi All, Please review fix for the below bug jdk12: Bug: https://bugs.openjdk.java.net/browse/JDK-8215364 Webrev: http://cr.openjdk.java.net/~pbansal/8215364/webrev.00/

Re: [12] RFR: JDK-8214805: Mark deprecated netscape.javascript.JSObject::getWindow API forRemoval=true

"The APIs in this package are all deprecated without replacement." On 05/12/2018 13:22, Phil Race wrote: Approved. -phil. On 12/4/18 7:21 PM, Kevin Rushforth wrote: Please review the webrev [1] for JDK-8214805 [2] to mark the already-deprecated netscape.javascript.JSObje

[12] RFR: JDK-8214805: Mark deprecated netscape.javascript.JSObject::getWindow API forRemoval=true

Please review the webrev [1] for JDK-8214805 [2] to mark the already-deprecated netscape.javascript.JSObject::getWindow method as "forRemoval=true". This method is no longer useful. We intend to remove it in a future release, which will also allow removing the dependency from the jdk.jsobject

Re: [8u-backport] JDK 8145547: [AWT/Swing] Conditional support for GTK 3 on Linux

. I have correct the same in webrev.02. It is just a typo and should not have any effect on functionality. All should work the same as 01 version. Webrev: http://cr.openjdk.java.net/~pbansal/gtk3_backport/webrev.02/ Regards, Pankaj -Original Message- From: Kevin Rushforth Sent: Saturday

Re: [8u-backport] JDK 8145547: [AWT/Swing] Conditional support for GTK 3 on Linux

/~pbansal/gtk3_backport/webrev.01/ SwingFXInteropTests: http://cr.openjdk.java.net/~pbansal/gtk3_backport/SwingFXInteropTests/ Please let me know if you would like me to do some further testing for Swing-FX interop. Regards, Pankaj Bansal -Original Message- From: Kevin Rushforth Sent

Re: [8u-backport] JDK 8145547: [AWT/Swing] Conditional support for GTK 3 on Linux

its ok, if I create new webrev when I get some more comments here. Regards, Pankaj Bansal *From:*Kevin Rushforth *Sent:* Wednesday, September 5, 2018 10:29 PM *To:* Pankaj Bansal; awt-dev@openjdk.java.net; swing-...@openjdk.java.net *Subject:* Re: [8u-backport] JDK 8145547: [AWT/Swing] Condi

Re: [8u-backport] JDK 8145547: [AWT/Swing] Conditional support for GTK 3 on Linux

The backport of the following fix, which removes sun.misc.GThreadHelper, will break all FX interop applications, even if GTK2 is used: https://bugs.openjdk.java.net/browse/JDK-8154546 : Retire sun.misc.GThreadHelper The FX GTK port still uses that class, so the class needs to be left in

Re: [11] Review Request: 8196030 and 8190326

I can confirm that the patch fixes the problem for me on the Windows 10 machine on which I initially reported the bug. The change in awt_Robot.cpp looks reasonable to me. I didn't review it thoroughly, though (and just skimmed the rest). -- Kevin On 5/18/2018 12:38 PM, Sergey Bylokhov

Re: [11] Review request for 8202084: [win] IME candidate window wrong position

wrote: Hi Kevin, Thanks for pointing (I didn't find it). Closed it as duplicate. Regards, Anton. On 4/20/2018 7:19 PM, Kevin Rushforth wrote: I think the first of these problems is the same as: https://bugs.openjdk.java.net/browse/JDK-8189687 Can you please check that and close JDK-8189687

Re: [11] Review request for 8202084: [win] IME candidate window wrong position

Thanks, Anton. -- Kevin On 4/20/2018 9:28 AM, Anton Tarasov wrote: Hi Kevin, Thanks for pointing (I didn't find it). Closed it as duplicate. Regards, Anton. On 4/20/2018 7:19 PM, Kevin Rushforth wrote: I think the first of these problems is the same as: https://bugs.openjdk.java.net

Re: [11] Review request for 8202084: [win] IME candidate window wrong position

I think the first of these problems is the same as: https://bugs.openjdk.java.net/browse/JDK-8189687 Can you please check that and close JDK-8189687 as a duplicate if so? Thanks. -- Kevin On 4/20/2018 8:51 AM, Anton Tarasov wrote: Hello! Could you please review the fix: Bug:

Re: RFR: 8198649 : Switch AWT/Swing's default GTK version to 3

This looks fine to me. I checked FX / Swing interop and it works as expected. If there is a mismatch in defaults (which there will be until FX switches the default, or after we which when running FX on an older JDK), then whichever toolkit loads first will use its default, and then the other

Re: [10] Review request for JDK-8190767: [macos] if JFrame is maximized on OS X, all new JFrames will be maximized by default

I can't speak to whether the logic is correct or not. I was just pointing out that the cast on line 692 is safe; since it is in an "if (target instanceof Frame)" block, "target" is already known to be a Frame. -- Kevin Sergey Bylokhov wrote: On 20/02/2018 11:35, K

Re: [10] Review request for JDK-8190767: [macos] if JFrame is maximized on OS X, all new JFrames will be maximized by default

The new code is already inside an "if (target instanceof Frame)" check... -- Kevin Sergey Bylokhov wrote: Hi, Manajit. You cannot cast the target to a Frame without any checks, because it is not necessary a Frame. On 16/02/2018 03:48, Manajit Halder wrote: Hi Sergey, Please review the

Re: Subject: [11] Review request for JDK-7158623: [macosx] Should an unfocusable maximized Frame be resizable?

> Kindly review the fix for JDK10. You mean JDK 11, right? -- Kevin Manajit Halder wrote: Hi All, Kindly review the fix for JDK10. Bug: https://bugs.openjdk.java.net/browse/JDK-7158623 Webrev: http://cr.openjdk.java.net/~mhalder/7158623/webrev.00/

Re: [8u-Backport] Review request for 8185634, 8187803 : Java Fx-Swing dialogs appearing behind main stage

I think you mean https://bugs.openjdk.java.net/browse/JDK-8187803 for the AWT/Swing side... -- Kevin Phil Race wrote: The AWT/Swing side of this needs to be bug https://bugs.openjdk.java.net/browse/JDK-8185634 One thing I notice is that in XWindowPeer.java the calculation for the value of

Re: [8u-Backport] Review request for 8185634, 8187803 : Java Fx-Swing dialogs appearing behind main stage

Hi Dipak, To underscore the fact that the AWT part of the change has to be pushed under a separate bug ID I have modified the subject line. The FX half of the implementation changes look fine. I tested it on Linux and it works as expected. There are two problems with the unit tests: 1. The

Re: [10] Review Request: 8182410, 8183508, 8181289

I can confirm the same behavior that Jon sees with Firefox 57 on Windows 7. The link scrolls to the right place with the link and does not with the link. -- Kevin Jonathan Gibbons wrote: Semyon, Using the files I previously posted, I confirm that I see the same display problem on a

Re: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage

some stress test which will try to force the possible crash: 4 threads: - show/dispose Swing Node - show/dispose Dialog1/2/3 using different timeouts Will the current fix cover the native dialogs like FileDialog/PrintDialog on linux and windows? On 10/10/2017 13:54, Kevin Rushforth wrote: Note

Re: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage

g1/2/3 using different timeouts Will the current fix cover the native dialogs like FileDialog/PrintDialog on linux and windows? On 10/10/2017 13:54, Kevin Rushforth wrote: Note that there is now a 04 version. It looks good to me, although someone more familiar with AWT should also check the AWT c

Re: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage

Note that there is now a 04 version. It looks good to me, although someone more familiar with AWT should also check the AWT changes. We will need a test program for this (as a follow-on issue if not now). -- Kevin Alexander Zvegintsev wrote: Please review the updated version

Re: Review Request: JDK-8179014 JFileChooser with Windows look and feel crashes on win 10 + jre-8 131

I'm not a "R"eviewer for AWT, but this part of the change looks wrong to me: case STRRET_CSTR : +if (pStrret->cStr != NULL) { return JNU_NewStringPlatform(env, reinterpret_cast(pStrret->cStr)); +} case STRRET_OFFSET : Did you really intended

Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method

David DeHaven wrote: David had said, it seems safer to leave it false for now and revisit marking for removal in 10 I think this means, "set forRemoval=false in 9, set forRemoval=true in 10, and actually remove it in 11". I said that in reference to Applet, not JSObject.

Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method

, Daniil -Original Message- From: Mandy Chung Sent: Thursday, June 09, 2016 9:23 AM To: Daniil Titov Cc: Erik Joelsson; David Dehaven; Stuart Marks; build-dev; build-infa-...@openjdk.java.net; awt-dev; Kevin Rushforth Subject: Re: Review Request: 8156960 Deprecate JSObject.getWindow

Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method

Yes, the plan is to deprecate it in 9 and remove it in a future release. -- Kevin Mandy Chung wrote: The client team owns jdk.jsobject module and so I add awt-dev to this thread. And bcc jdk9-dev. It is not Java SE API and it should not add to CORE-PKGS.gmk. As for @Deprecated, I believe

Re: RFR: 8154546: Retire sun.misc.GThreadHelper

This seems good to me. -- Kevin Philip Race wrote: On 5/12/16, 7:34 AM, Sergey Bylokhov wrote: On 12.05.16 17:23, Philip Race wrote: Probably we should skip the loading of glib >= 2.2 <=2.29 and bump the minumum version to 2.20/2.24? This will eliminate the possibility of the crash. Not

Re: RFR: 8155772: gtk3_interface.c compilation error on Ubuntu 12.10

I am not a "R" reviewer for AWT, but using NULL as if it were an int is incorrect, so this fix looks good to me. -- Kevin Phil Race wrote: Bug : https://bugs.openjdk.java.net/browse/JDK-8155772 On my system in this file it appears NULL is "#define (void*)0 which causes the error "error:

Re: RFR [9] 8146735: Move sun.misc.PerformanceLogger to sun.util.logging

https://bugs.openjdk.java.net/browse/JDK-8147010 -- Kevin Chris Hegarty wrote: On 12/01/16 22:44, Kevin Rushforth wrote: I note that JavaFX optionally uses sun.misc.PerformanceLogger this in one place (via reflection). We'll need to file a new issue to clean this up. Thanks Kevin. Can you

Re: RFR [9] 8146735: Move sun.misc.PerformanceLogger to sun.util.logging

I note that JavaFX optionally uses sun.misc.PerformanceLogger this in one place (via reflection). We'll need to file a new issue to clean this up. -- Kevin Mandy Chung wrote: On Jan 12, 2016, at 10:30 AM, Chris Hegarty wrote: Webrev updated in-place, moved to

Re: Java 8 updates are causing "Apps that use non-public APIs will be rejected"

[moving this back to the openjfx alias; Bcc awt-dev] The javapackager fix for JDK 8u72 does exactly this when generating .pkg files. So in short, libjfxwebkit.dylib is unchanged for 8u72, but will be excluded when generating an app for the Apple app store. -- Kevin Michael Hall wrote: On

Re: AWT Dev [9] Review Request: 8074763 Remove API references to java.awt.dnd.peer

Hi Anton, Yes, there are concerns regarding this, mainly due to the timing and build issues. After this week we are no longer auto-syncing changes from 8u-dev into 9, so we are at a good point to do this, but it will need to be done carefully. I expect that we will need at least 2 weeks to

Re: AWT Dev [9] Review Request: 8074763 Remove API references to java.awt.dnd.peer

The change looks fine to me. I tried to apply the patch (to verify that it doesn't affect JFXPanel) but got merge conflicts with the latest (as of today) jdk9/client/jdk repo. As long as Anton has verified that it doesn't break compatibility with JFXPanel I am OK with the change. -- Kevin

Re: AWT Dev [OpenJDK 2D-Dev] [9] Review Request: 8074028 Remove API references to java.awt.peer

I verified that this doesn't break JavaFX Swing interop (specifically Drag and Drop), so it looks fine to me. -- Kevin Sergey Bylokhov wrote: The new version of the fix: http://cr.openjdk.java.net/~serb/8074028/webrev.06 Font.getPeer() was renamed to Font.getFontPeer(). On 04.03.2015

Re: AWT Dev [OpenJDK 2D-Dev] [9] Review Request: JDK-8029455 JLightweightFrame: support scaled painting

PS. I'll be pushing the FX part of the fix today. So we should consider the current interface frozen for now. Yes, please! -- Kevin Anthony Petrov wrote: On 5/23/2014 3:12 PM, Anton V. Tarasov wrote: On 23.05.2014 14:47, Anthony Petrov wrote: 1. The host bounds are not related to the