Re: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules [v2]

On Wed, 25 Aug 2021 12:47:41 GMT, Andrey Turbanov wrote: >> src/java.base/share/classes/java/net/URLPermission.java line 222: >> >>> 220: >>> 221: List l = normalizeMethods(methods); >>> 222: l.sort(null); >> >> I am not opposed to this change, but I find this is slightly

Re: RFR: 8272806: [macOS] "Apple AWT Internal Exception" when input method is changed

On Sun, 22 Aug 2021 19:46:49 GMT, Phil Race wrote: > There's a long eval in the bug report : > https://bugs.openjdk.java.net/browse/JDK-8272806 but here's the summary > > When focus is lost by the app a message is sent down to native setting a > native reference to the input method to null >

Re: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules

On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method > directly. There are a bunch of calls to `Collections.sort()` without a comparator specified (at least in java.desktop):

Re: RFR: 8271456: Avoid looking up standard charsets in "java.desktop" module

On Sun, 1 Aug 2021 07:07:21 GMT, Sergey Bylokhov wrote: > This is a request to clean up a desktop module as was done in JDK-8233884 for > "java.base" module. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be

Re: RFR: 8271456: Avoid looking up standard charsets in "java.desktop" module

On Sun, 1 Aug 2021 07:07:21 GMT, Sergey Bylokhov wrote: > This is a request to clean up a desktop module as was done in JDK-8233884 for > "java.base" module. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be

[jdk17] Integrated: 8015886: java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java sometimes failed on ubuntu

On Thu, 22 Jul 2021 19:53:37 GMT, Alexander Zvegintsev wrote: > This test can fail pretty consistently on some slow systems. Increased delay > fixes the issue. > We do have similar fix in #260 This pull request has now been integrated. Changeset: 049b2ad4 Author:Alexander Z

Re: [jdk17] RFR: 8015886: java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java sometimes failed on ubuntu [v4]

On Fri, 23 Jul 2021 12:56:32 GMT, Alexander Zvegintsev wrote: >> This test can fail pretty consistently on some slow systems. Increased delay >> fixes the issue. >> We do have similar fix in #260 > > Alexander Zvegintsev has updated the pull request incrementally with

Re: [jdk17] RFR: 8015886: java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java sometimes failed on ubuntu [v4]

> This test can fail pretty consistently on some slow systems. Increased delay > fixes the issue. > We do have similar fix in #260 Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: finally dispose -

Re: [jdk17] RFR: 8015886: java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java sometimes failed on ubuntu [v3]

On Fri, 23 Jul 2021 11:53:48 GMT, Prasanta Sadhukhan wrote: > Looks good. BTW, normally in swing we also do dispose of the frame after test > is over in finally block...Not sure in awt Frame...It may not be required if > you are running standalone but in a group of CI run, it might prove >

Re: [jdk17] RFR: 8015886: java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java sometimes failed on ubuntu [v3]

> This test can fail pretty consistently on some slow systems. Increased delay > fixes the issue. > We do have similar fix in #260 Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: increased delay -

Re: [jdk17] RFR: 8015886: java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java sometimes failed on ubuntu

On Thu, 22 Jul 2021 20:20:48 GMT, Alexander Zuev wrote: > I am not sure if we supposed to bump up the copyright year or it is supposed > to be done with some script later, but i usually do it myself just to be sure. updated - PR: https://git.openjdk.java.net/jdk17/pull/272

Re: [jdk17] RFR: 8015886: java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java sometimes failed on ubuntu [v2]

> This test can fail pretty consistently on some slow systems. Increased delay > fixes the issue. > We do have similar fix in #260 Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: year bump - Changes

[jdk17] RFR: 8015886: java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java sometimes failed on ubuntu

This test can fail pretty consistently on some slow systems. Increased delay fixes the issue. We do have similar fix in #260 - Commit messages: - initial Changes: https://git.openjdk.java.net/jdk17/pull/272/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17=272=00

Re: Call for Discussion : New Project to support the Wayland display server on Linux

(adding awt-dev) Let me add a few comments. already Wayland is the default on RHEL 8, OL 8, Ubuntu 21.04 and I am sure others too. It is the default, but not in every case. Wayland may be turned off deliberately if you are using a Nvidia graphics card, so you need to take extra steps to get

Integrated: 8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS)

On Mon, 29 Mar 2021 18:57:55 GMT, Alexander Zvegintsev wrote: > This fix is to explicitly specify that `Taskbar::getIconImage` may return an > object different from passed to `Taskbar::setIconImage`. > > Actually it is always returns a different object on macOS(the only OS which

Re: RFR: 8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS) [v4]

On Thu, 17 Jun 2021 20:31:07 GMT, Phil Race wrote: >> Alexander Zvegintsev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> header fix > > src/java.desktop/share/classes/java/awt/Taskbar.java line

Re: RFR: 8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS) [v5]

ns if we decide to > rework this. Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: @apiNote added, Suggests -> Requests - Changes: - all: https://git.openjdk.java.net/jdk/pull/3250/files - new: https://git.open

Re: RFR: 8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS) [v4]

ns if we decide to > rework this. Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: header fix - Changes: - all: https://git.openjdk.java.net/jdk/pull/3250/files - new: https://git.openjdk.java.net/jdk/pull/3

Re: RFR: 8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS) [v3]

ns if we decide to > rework this. Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: update - Changes: - all: https://git.openjdk.java.net/jdk/pull/3250/files - new: https://git.openjdk.java.net/jdk/pull/3250/files/

Re: RFR: 8268620: InfiniteLoopException test may fail on x86 platforms

On Mon, 14 Jun 2021 17:18:15 GMT, Sergey Bylokhov wrote: > Small test update. > > This test posts lots of events to EDT from the different threads, and it > checks that the robot.waitForIdle() on the main thread will not hang or throw > an exception. And this test fails on x86. The post of

Re: RFR: 8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to set display mode!

On Sat, 5 Jun 2021 15:07:27 GMT, Phil Race wrote: > There are two issues here, both macOS specific. > First the original reported one that occurs when running on a shared remote > VNC type desktop on macOS. > Only a single supported display mode is returned and it is also the current > mode. >

Re: RFR: 8267307: Introduce new client property for XAWT: xawt.mwm_decor_title [v2]

On Fri, 4 Jun 2021 08:44:22 GMT, Maxim Kartashev wrote: >> This commit introduces a new client property xawt.mwm_decor_title >> implementing JDK-8267307. The property can be set prior to showing a window >> or after the window has been displayed, in which case the window will have >> to be

Re: RFR: 8267307: Introduce new client property for XAWT: xawt.mwm_decor_title

On Wed, 19 May 2021 10:23:01 GMT, Maxim Kartashev wrote: > This commit introduces a new client property xawt.mwm_decor_title > implementing JDK-8267307. The property can be set prior to showing a window > or after the window has been displayed, in which case the window will have to > be

Re: RFR: 8267307: Introduce new client property for XAWT: xawt.mwm_decor_title

On Wed, 19 May 2021 10:23:01 GMT, Maxim Kartashev wrote: > This commit introduces a new client property xawt.mwm_decor_title > implementing JDK-8267307. The property can be set prior to showing a window > or after the window has been displayed, in which case the window will have to > be

Re: RFR: 8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS) [v2]

On Wed, 26 May 2021 17:51:55 GMT, Alexander Zvegintsev wrote: >> This fix is to explicitly specify that `Taskbar::getIconImage` may return an >> object different from passed to `Taskbar::setIconImage`. >> >> Actually it is always returns a different object on

Re: RFR: 8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS) [v2]

ns if we decide to > rework this. Alexander Zvegintsev 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 three additional commits since the last revision:

Re: RFR: 8266949: Check possibility to disable OperationTimedOut on Unix [v2]

On Sun, 16 May 2021 01:29:59 GMT, Sergey Bylokhov wrote: >> Our implementation of realSync on Unix is not straightforward, we try to >> move the awt root window and catch the ConfigureNotify. The problem is that >> the request to move the awt root window can be ignored, and it is possible >>

Re: RFR: 8182043: Access to Windows Large Icons [v8]

On Mon, 17 May 2021 05:13:06 GMT, Alexander Zuev wrote: >> Fix updated after first round of review. > > Alexander Zuev has updated the pull request incrementally with one additional > commit since the last revision: > > Example in JavaDoc fixed Marked as reviewed by azvegint (Reviewer).

Re: RFR: 8182043: Access to Windows Large Icons [v7]

On Fri, 14 May 2021 19:46:03 GMT, Alexander Zuev wrote: >> Fix updated after first round of review. > > Alexander Zuev has updated the pull request incrementally with one additional > commit since the last revision: > > Slight change of wording in javadoc > Fixed

Re: RFR: 8047218: [TEST_BUG] java/awt/FullScreen/AltTabCrashTest/AltTabCrashTest.java fails with exception

On Mon, 10 May 2021 21:38:37 GMT, Sergey Bylokhov wrote: > An exception occurs when the main thread disposes of the frame while the > other thread still renders to it. The fix joins the main thread to other > threads, so we will dispose of the frame at the end only. Marked as reviewed by

Re: RFR: 8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS)

On Fri, 7 May 2021 19:57:02 GMT, Phil Race wrote: > Leaving aside specification. what does an app really want this to return ? > Should we start from there ? We are returning current dock icon image from system. > Do we definitely not want to just hang on to whatever an application set so >

Re: RFR: 8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS)

On Mon, 29 Mar 2021 18:57:55 GMT, Alexander Zvegintsev wrote: > This fix is to explicitly specify that `Taskbar::getIconImage` may return an > object different from passed to `Taskbar::setIconImage`. > > Actually it is always returns a different object on macOS(the only OS which

Re: RFR: 8264786: [macos] All Swing/AWT apps cause Allow Notifications prompt to appear when app is launched

On Tue, 27 Apr 2021 01:09:44 GMT, Sergey Bylokhov wrote: > The fix for the JDK-8187639 reimplemented the tray icon messages using the > standard notification center, it worked fine on macOS 10.9. But on the new > macOS, the usage of that API requests permission from the user. Since the > code

Re: RFR: 8197821: Test java/awt/font/TextLayout/LigatureCaretTest.java fails on Windows

On Wed, 28 Apr 2021 12:46:56 GMT, Prasanta Sadhukhan wrote: > 2 tests java/awt/font/TextLayout/LigatureCaretTest.java and > java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java used to > fail on windows in CI testing citing "wrong text location" and " right hit > failed

Re: RFR: 8168408: Test java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java fails intermittentently on windows

On Wed, 21 Apr 2021 11:15:49 GMT, Prasanta Sadhukhan wrote: > This test was seen to be failing in windows and mac PIT run due to samevm > mode issue. It is now passing in default othervm mode. > Several iterations of this test running in all platforms is working fine, > link in JBS. > We can

Re: RFR: 8198422: Test java/awt/font/StyledMetrics/BoldSpace.java is unstable

On Wed, 21 Apr 2021 11:08:40 GMT, Prasanta Sadhukhan wrote: > This test was marked as unstable in CI run due to samevm mode issue. It is > now passing in default othervm mode. > Several iterations of this test running in all platforms is working fine, > link in JBS. > We can remove the test

Integrated: 8039261: [TEST_BUG]: There is not a minimal security level in Java Preferences and the TestApplet.html is blocked.

On Mon, 12 Apr 2021 18:48:06 GMT, Alexander Zvegintsev wrote: > This fix simply removes tests mentioned in the bug with for unsupported > scenarios(applets in browser). This pull request has now been integrated. Changeset: 26186ec3 Author:Alexander Zvegintsev URL:

Re: RFR: 8039261: [TEST_BUG]: There is not a minimal security level in Java Preferences and the TestApplet.html is blocked. [v2]

On Tue, 13 Apr 2021 01:03:49 GMT, Sergey Bylokhov wrote: >> Alexander Zvegintsev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> TestApplet.java removed > > test/jdk/java/awt/event/Ke

Re: RFR: 8039261: [TEST_BUG]: There is not a minimal security level in Java Preferences and the TestApplet.html is blocked. [v2]

> This fix simply removes tests mentioned in the bug with for unsupported > scenarios(applets in browser). Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: TestApplet.java removed - Changes: - all:

Re: RFR: 8039261: [TEST_BUG]: There is not a minimal security level in Java Preferences and the TestApplet.html is blocked.

On Mon, 12 Apr 2021 20:23:39 GMT, Sergey Bylokhov wrote: > Please confirm that none of them are in the problem list. I do confirm that. - PR: https://git.openjdk.java.net/jdk/pull/3441

RFR: 8039261: [TEST_BUG]: There is not a minimal security level in Java Preferences and the TestApplet.html is blocked.

This fix simply removes tests mentioned in the bug with for unsupported scenarios(applets in browser). - Commit messages: - initial Changes: https://git.openjdk.java.net/jdk/pull/3441/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3441=00 Issue:

Re: RFR: 8233567: [TESTBUG] FocusSubRequestTest.java fails on macos

On Mon, 12 Apr 2021 04:37:31 GMT, Prasanta Sadhukhan wrote: > This test was problemlisted during nightly testing of jdk on macos which > seems to be caused by the fact that proper waiting was not done to make sure > frame is visible before commencing the test, which can be problematic in some

Re: RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v4]

On Thu, 8 Apr 2021 14:43:50 GMT, Andrey Turbanov wrote: >> There are few possible cleanups in java.desktop related to legacy >> StringBuffer usages: >> 1. In few places StringBuffer can be replaced with plain String >> concatenation. >> 2. StringBuffer can be replaced with StringBuilder.

Re: RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v3]

On Wed, 7 Apr 2021 06:39:48 GMT, Andrey Turbanov wrote: >> There are few possible cleanups in java.desktop related to legacy >> StringBuffer usages: >> 1. In few places StringBuffer can be replaced with plain String >> concatenation. >> 2. StringBuffer can be replaced with StringBuilder.

Re: RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v2]

On Tue, 30 Mar 2021 19:05:37 GMT, Andrey Turbanov wrote: >> There are few possible cleanups in java.desktop related to legacy >> StringBuffer usages: >> 1. In few places StringBuffer can be replaced with plain String >> concatenation. >> 2. StringBuffer can be replaced with StringBuilder.

Re: RFR: 8264680: Use the blessed modifier order in java.desktop [v2]

On Sat, 3 Apr 2021 22:28:54 GMT, Alex Blewitt wrote: >> 8264680: Use the blessed modifier order in java.desktop > > Alex Blewitt has updated the pull request incrementally with one additional > commit since the last revision: > > Additionally remove detritus from PNGImageDecoder.java

RFR: JDK-8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS)

JDK-8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS) - Commit messages: - initial Changes: https://git.openjdk.java.net/jdk/pull/3250/files Webrev:

Re: RFR: 8264344: Outdated links in JavaComponentAccessibility.m

On Mon, 29 Mar 2021 08:31:48 GMT, Alexander Zuev wrote: > 8264344: Outdated links in JavaComponentAccessibility.m Marked as reviewed by azvegint (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3240

Re: RFR: 8260619: Add final modifier to several DataFlavor static fields

On Mon, 22 Mar 2021 22:03:15 GMT, Sergey Bylokhov wrote: > This request proposes changing the state of a few static constants in the > DataFlavor class. > > The fields selectionHtmlFlavor/fragmentHtmlFlavor/allHtmlFlavor added to the > java.awt.datatransfer.DataFlavor class in JDK8 were not

Re: RFR: 8263846: Bad JNI lookup getFocusOwner in accessibility code on Mac OS X

On Fri, 19 Mar 2021 23:10:46 GMT, Alexander Zuev wrote: > 8263846: Bad JNI lookup getFocusOwner in accessibility code on Mac OS X Since there is no test, I assume that the JBS issue should have `noreg-hard` label. - Marked as reviewed by azvegint (Reviewer). PR:

Integrated: 8194129: Regression automated Test '/open/test/jdk/java/awt/Window/ShapedAndTranslucentWindows/TranslucentChoice.java' fails

On Fri, 12 Mar 2021 00:25:39 GMT, Alexander Zvegintsev wrote: > First steps of the test are: > > - display undecorated background window > - click on it > - check if the window has received that click > - ... continue with test ... > > Unfortunately on Linux the

RFR: 8194129: Regression automated Test '/open/test/jdk/java/awt/Window/ShapedAndTranslucentWindows/TranslucentChoice.java' fails

First steps of the test are: - display undecorated background window - click on it - check if the window has received that click - ... continue with test ... Unfortunately on Linux the test makes click before the window is shown. - Commit messages: - initial Changes:

Integrated: 8250804: Can't set the application icon image for Unity WM on Linux.

On Fri, 5 Mar 2021 00:55:04 GMT, Alexander Zvegintsev wrote: > As of now we can have two icons: on the side dock and on the top bar. > But this test was written for an old time Unity with an icon in the side dock > only. > > Icon at the top by default is displayed as grays

Re: RFR: 8250804: Can't set the application icon image for Unity WM on Linux.

On Fri, 5 Mar 2021 01:18:26 GMT, Sergey Bylokhov wrote: >> test/jdk/ProblemList.txt line 855: >> >>> 853: >>> java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java >>> 8162380 generic-all >>> 854: java/awt/Window/TranslucentJAppletTest/TranslucentJAppletTest.java >>>

RFR: 8250804: Can't set the application icon image for Unity WM on Linux.

As of now we can have two icons: on the side dock and on the top bar. But this test was written for an old time Unity with an icon in the side dock only. Icon at the top by default is displayed as grayscale(the actual reason of submitting bug report). BTW it may not be presented depending on

Re: RFR: JDK-8262461: handle wcstombsdmp return value correctly in unix awt_InputMethod.c

On Fri, 26 Feb 2021 14:19:03 GMT, Matthias Baesken wrote: > The function wcstombsdmp is called at a few places in awt_InputMethod.c. > This function needs checking of a NULL return value and freeing of the memory > allocated by this function. However this is missing at one place in the file.

Re: RFR: JDK-8262420: typo: @implnote in java.desktop module

On Thu, 25 Feb 2021 23:15:03 GMT, Jonathan Gibbons wrote: > Please review some doc changes in `java.awt.TrayIcon`. > > Note, the fix is more than the 1-character fix for the typo detected by > doclint. The changes are: > > 1. Fix the name of the `@implNote` tag > 2. Remove the redundant ``

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

on mac? --Semyon On 11/07/2017 10:11 AM, Alexander Zvegintsev wrote: Hi Sergey, I am not able to crash it on several platforms, except one case: if we are terminating JavaFX application while EDT processing some long task. But it is unrelated to the fix and reproducible on current builds

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

log 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 changes. We will need a test program for this (as a follow-on issue if not now). -- Kevin Alexande

Re: [10] Review Request 8190230: [macosx] Order of overlapping of modal dialogs is wrong

Hi Semyon, the fix looks good to me,  but the test link is broken in this webrev. Thanks, Alexander. On 30/10/2017 20:37, Semyon Sadetsky wrote: Hello, Please review fix for JDK10: bug: https://bugs.openjdk.java.net/browse/JDK-8190230 webrev:

Re: [10] Review request for JDK-8163265: [macosx] numpad 0 instead of VK_0

+1 Thanks, Alexander. On 17/10/2017 03:12, Sergey Bylokhov wrote: Looks fine. Please update the @bugid in the test before the push. On 16/10/2017 06:38, Manajit Halder wrote: Hi All, Kindly review the fix for JDK10. Bug: https://bugs.openjdk.java.net/browse/JDK-8163265 Webrev:

Re: [10] Review request for 8182638: [macosx] Active modal dialog is hidden by another non-active one

Looks good to me, BTW in the test DialogListener can be replaced with WindowAdapter Thanks, Alexander. On 07/10/2017 01:17, Semyon Sadetsky wrote: Hello, Please review fix for JDK10: bug: https://bugs.openjdk.java.net/browse/JDK-8182638 webrev:

Re: [10] Review Request: 8187639 TrayIcon is not properly supported on macOS in multi-screen environment

Looks fine Thanks, Alexander. On 27/09/2017 22:37, Sergey Bylokhov wrote: Hello, Please review the fix for jdk10. Bug: https://bugs.openjdk.java.net/browse/JDK-8187639 Webrev can be found at: http://cr.openjdk.java.net/~serb/8187639/webrev.01 Since macOS 10.9(or even early) the main

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

rWindowPtr, ptr, CWrapper.NSWindow.NSWindowAbove); <<<<< Boom } On 9/21/17 22:56, Alexander Zvegintsev wrote: Hi Phil, Please review the updated fix with reflection incorporated http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/ New issue created JDK-8187803 <https:/

Re: [10] Review request for 8166772: Touch keyboard is not shown for text components on a screen touch

+1 Thanks, Alexander. On 22/09/2017 06:09, Anton Litvinov wrote: Hello Sergey, Thank you very much for review of this fix. The second version of the fix with minor changes in 3 places which address your remarks is created. The new fix version applied to the today's version of the

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

= peer.getOverridenWindowHandle(); <<<<< Dispose the peer if (ownerWindowPtr != 0) {     //Place window above JavaFX stage     CWrapper.NSWindow.addChildWindow(     ownerWindowPtr, ptr, CWrapper.NSWindow.NSWindowAbove); <<<<< Boom } On 9/21/17 22:56, Alexander Zvegintsev wrote: Hi Phil,

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

f-line that as in the dialog case, the FX side of the code can use reflection and simply be a harmless non-functional no-op if the SwingAccessor does not provide the new method. BTW 264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; } should be "dd" not "d". -phil. On 09/21/2017 03:3

Re: [10] Review Request: 8186474 WColor class is superseded by the SystemColor and should be removed

Looks fine Thanks, Alexander. On 19/08/2017 07:34, Sergey Bylokhov wrote: Hello, Please review the simple cleanup for jdk10. Long time ago AWT used WColor class to access the native colors, but since then we integrated a public API via SystemColor class. So WColor class became obsolete and

Re: [10] Review request for 8178448: MenuBar item handler fired twice

, Alex. Is it possible to create a test for this issue? It will be similar to ActionListenerCalledTwiceTest On 01.08.2017 22:34, Alexander Zvegintsev wrote: Hi all, please review the fix http://cr.openjdk.java.net/~azvegint/jdk/10/8178448/00/ for the issue https://bugs.openjdk.java.net/browse

[10] Review request for 8178448: MenuBar item handler fired twice

Hi all, please review the fix http://cr.openjdk.java.net/~azvegint/jdk/10/8178448/00/ for the issue https://bugs.openjdk.java.net/browse/JDK-8178448 This Mac specific issue happens if setDefaultMenuBar() is called after setJMenuBar() with same instance of JMenuBar. JFrame.setJMenuBar(mb);

Re: [10] Review request for 8139050 -[AWTView draggingEnded:]: unrecognized selector message during drag and drop

Looks good to me. Thanks, Alexander. On 21/07/2017 04:02, Sergey Bylokhov wrote: Hello. We got a response from the previous maintainer of this code, that it was implemented long time ago, and works probably because of a different class hierarchy. Currently the code works in this way:

Re: [9] Review Request: 8180326 Update the tables in java.desktop to be HTML-5 friendly

Thanks for clarification, looks good to me. Thanks, Alexander. On 07/06/2017 23:22, Sergey Bylokhov wrote: Hi, Alexander. These closing tags are optional in html5 standard [1]. On the link to the SO there are three the example which work differently but according standards[2][3][4]. [1]

Re: [9] Review Request: 8180889 Cleanup of javadoc in java.datatransfer module

Looks good to me. Thanks, Alexander. On 25/05/2017 06:54, Sergey Bylokhov wrote: Hi, Phil. Thank you for a review, the fix is updated: Webrev can be found at: http://cr.openjdk.java.net/~serb/8180889/webrev.01 Specdiff:

Re: [9] Review Request: 8180326 Update the tables in java.desktop to be HTML-5 friendly

Hi Sergey, Why do we omitting closing th tag? e.g. + * Metal's system color mapping + * + * + * Key + * Value + * I know that HTML parsers are usually forgiving such things. But sometimes it may make thing worse:

[9] Review request for 8178996 [macos] JComboBox doesn't display popup in mixed JavaFX Swing Application on 8u131 and Mac OS 10.12

Hi all, please review the fix http://cr.openjdk.java.net/~azvegint/jdk/9/8178996/00/ for the issue https://bugs.openjdk.java.net/browse/JDK-8178996 Popup doesn't show up due to owner is lightweight frame and doesn't have a native pointer, thus we do not invoke owner.execute() code block,

[9] Review request for 8177919: java.awt.Desktop.setDefaultMenuBar​() should be specified to throw IllegalStateException

Hello, please review the fix http://cr.openjdk.java.net/~azvegint/jdk/9/8177919/00/ for the issue https://bugs.openjdk.java.net/browse/JDK-8177919 This fix removes throwing of ISE, this allows to use default menu bar with LaF's other than Aqua (with apple.laf.useScreenMenuBar set to true).

Re: [9] Review request for 8176528: Progress state for window is not displayed in taskbar

How about that version? http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/04/ Thanks, Alexander. On 15/03/2017 20:18, Philip Race wrote: Even if all we can add (to what is already proposed) is "whether an icon for a window is displayable in the task bar is dependent on all of window type,

Re: [9] Review request for 8176528: Progress state for window is not displayed in taskbar

It turned out that if Dialog has no owner(e.g. new Dialog((Frame) null)) it is visible in the taskbar. So I am reverting API change. http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/03/ Thanks, Alexander. On 14/03/2017 23:43, Alexander Zvegintsev wrote: It has no representation on windows

Re: [9] Review request for 8176528: Progress state for window is not displayed in taskbar

with this change ? -phil On 3/14/17, 5:54 AM, Alexander Zvegintsev wrote: There is no precedents here: http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/02/ Thanks, Alexander. On 14/03/2017 15:40, Philip Race wrote: with this change maybe we should be renaming the parameters and update the doc

Re: [9] Review request for 8176528: Progress state for window is not displayed in taskbar

an important case with this change ? -phil On 3/14/17, 5:54 AM, Alexander Zvegintsev wrote: There is no precedents here: http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/02/ Thanks, Alexander. On 14/03/2017 15:40, Philip Race wrote: with this change maybe we should be renaming the parameters

Re: [9] Review request for 8176528: Progress state for window is not displayed in taskbar

? Or is there precedent for what you have right now ? -phil. On 3/14/17, 5:33 AM, Alexander Zvegintsev wrote: So they already know the window isn't visible and are asking for an explanation of the circumstances for this so I don't think this update will satisfy them without more explanation. At the very

Re: [9] Review request for 8176528: Progress state for window is not displayed in taskbar

de Window}s are not visible in the task bar. For example undecorated Windows may not be visible". I do not know if we can say something stronger than that ? Is this the case on all platforms ? -phil. On 3/13/2017 2:04 PM, Alexander Zvegintsev wrote: Hello, please review the fix http://cr.

[9] Review request for 8176528: Progress state for window is not displayed in taskbar

Hello, please review the fix http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/00/ for the issue https://bugs.openjdk.java.net/browse/JDK-8176528 The test uses java.awt.Window which doesn't have button for its window in the taskbar, thus we can't show progress for this window there. --

Re: [9] Review request for 8175301 Java GUI hangs on Windows when Display set to 125%

+1 Thanks, Alexander. On 09/03/2017 13:48, Sergey Bylokhov wrote: Looks fine. Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8175301/webrev.01 There are two places where D3DSurfaceData.swapBuffers() is called D3DScreenUpdateManager.run() and

Re: [9] Review request for 8176097 Window set location to a display with different DPI does not properly work

+1 -- Thanks, Alexander. On 05.03.2017 21:25, Sergey Bylokhov wrote: Looks fine. Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8176097/webrev.02 - sysX and sysY values are kept the the same as the passed x and y values. Thanks, Alexandr. On 3/3/2017

Re: [JDK-8048731] com.apple.eawt.FullScreenUtilities#setWindowCanFullScreen

Hello, there is no replacement for setWindowCanFullScreen(), resizable windows are made fullscreenable by default(JDK-8143914 ). However there is unofficial way to override it:

Re: [9] Review Request: 8168307 Toolkit.getScreenSize() returns incorrect size on unix in multiscreen systems

+1 -- Thanks, Alexander. On 02.03.2017 12:11, Alexandr Scherbatiy wrote: The fix looks good to me. Thanks, Alexandr. On 2/28/2017 8:21 PM, Sergey Bylokhov wrote: Hi, Alexander. The XToolkit.getDefaultScreenWidth()/getDefaultScreenHeight() methods are supposed to return the width/height in

Re: [9] Review Request: 8176009 The awt robot use incorrect location in a multi-screen environment

+1 -- Thanks, Alexander. On 01.03.2017 12:55, Sergey Bylokhov wrote: Hello, Please review the fix for jdk9. The fix reverts the changes which were introduced in JDK-8145784(the test SpuriousMouseEvents.java was updated in JDK-8163270). The fix was tested in multiscreen environment on linux,

Re: [9] Review Request: 8033128 Javadoc change is required for java.awt.Robot(GraphicsDevice screen) constructor

+1 Thanks, Alexander. On 14/02/2017 15:24, Sergey Bylokhov wrote: Hello, Please review the fix for jdk9. In the fix the «getPixelColor» is added to the list of methods which affected by this constructor. Also the notion «This constructor is meant for the latter case» is removed, because

[9] Review request for 8166313: JavaDoc mentions AppEvent subclasses as inner class of AppEvent

Hello, please review the doc fix http://cr.openjdk.java.net/~azvegint/jdk/9/8166313/00/ for the issue https://bugs.openjdk.java.net/browse/JDK-8166313 This is a simple clean up fix. -- Thanks, Alexander.

Re: RFR: 8167228: Update to libpng 1.6.28

+1 Thanks, Alexander. On 23/01/2017 18:35, Sergey Bylokhov wrote: Looks fine. Webrev: http://cr.openjdk.java.net/~prr/8167228/ This fix updates libpng in JDK 9 to the current version 1.6.28. Aside from updating to these files there are few changes to note (1) The CHANGES file has

Re: [9] Review request for 8165705: Robot.createScreenCapture produces black screenshot on Oracle Linux 7.1

Sure, updated in place. Thanks, Alexander. On 01/09/2017 06:09 PM, Sergey Bylokhov wrote: Looks fine. But it seems that this field can be removed? private static boolean isGtkSupported =false; After the fix for JDK-8150954 this field is not used. Hello, please review the fix

Re: [9] Review request for 8166683: On macOS (Mac OS X) getting a ScreenMenuBar when not running "com.apple.laf.AquaLookAndFeel"

. On 11/29/16 4:12 AM, Alexander Zvegintsev wrote: I don't find any modern jdk9 prefix convention for such property, so I've named it "jdk.swing.disableForcedGlobalMenuBar" http://cr.openjdk.java.net/~azvegint/jdk/9/8166683/02/ Thanks, Alexander. On 11/28/16 9:05 PM, Sergey Bylokhov wro

Re: [9] Review request for 8166683: On macOS (Mac OS X) getting a ScreenMenuBar when not running "com.apple.laf.AquaLookAndFeel"

thing like "globalMenuBar", etc? At least this will allow us to change implementation in any ways on other platforms w/o changing/adding the old/new properties. On 15.11.16 17:39, Alexander Zvegintsev wrote: Hi Sergey, I've not found casting issues, but I've found the issue when previous

Re: [9] Review request for 8151189: Possible getAppContext() NPE in java.awt.Desktop and java.awt.Taskbar

alled by the user then appcontext should not be null, additionally we should not cache this value in the static, so all other code will use this cached static value. On 15.11.16 20:38, Phil Race wrote: +1 -phil. On 11/15/2016 08:24 AM, Alexander Zvegintsev wrote: Hello, please review the fix ht

[9] Review request for 8151189: Possible getAppContext() NPE in java.awt.Desktop and java.awt.Taskbar

Hello, please review the fix http://cr.openjdk.java.net/~azvegint/jdk/9/8151189/00/ for the issue https://bugs.openjdk.java.net/browse/JDK-8151189 -- Thanks, Alexander.

Re: [9] Review request for 8166683: On macOS (Mac OS X) getting a ScreenMenuBar when not running "com.apple.laf.AquaLookAndFeel"

vegint/jdk/9/8166683/01/ Thanks, Alexander. On 11/11/16 2:14 PM, Sergey Bylokhov wrote: Hi, Alexander. Did you run the tests on non-Aqua l? I assume that we can have a places in other l where we try to cast the MenuBarUI to some specific UI delegate. On 09.11.16 16:58, Alexander Zvegin

[9] Review request for 8166683: On macOS (Mac OS X) getting a ScreenMenuBar when not running "com.apple.laf.AquaLookAndFeel"

Hello, please review the fix http://cr.openjdk.java.net/~azvegint/jdk/9/8166683/00/ for the issue https://bugs.openjdk.java.net/browse/JDK-8166683 This fix adds support for ScreenMenuBar for L's other than Aqua. With this fix it is enabled by default if apple.laf.useScreenMenuBar property

Re: [9] Review request for 8163101: dual-screen issue with JMenu, JPopupMenu

+1 Thanks, Alexander. On 8/31/16 5:18 PM, Semyon Sadetsky wrote: Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8163101 webrev: http://cr.openjdk.java.net/~ssadetsky/8163101/webrev.00/ In the 8137571 the available screen area request

Re: [9] Review request for 8159432: [PIT][macosx] StackOverflow in closed/java/awt/Dialog/DialogDeadlock/DialogDeadlockTest

+1 Thanks, Alexander. On 11/1/16 10:59 PM, Sergey Bylokhov wrote: Looks fine. On 05.10.16 11:45, Semyon Sadetsky wrote: To avoid this the 8139218 solution is revisited to manage the focus restore synchronously only if it is possible and send a single asynchronous focus request otherwise.

  1   2   3   4   >