Swing Dev hg: jdk7/swing/jdk: 7034619: Scrollable Tabs don't appear with JDK7 Synth based LaF, different from Java 5/6

Changeset: 523ad3855e03 Author:kizune Date: 2011-05-10 17:06 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/523ad3855e03 7034619: Scrollable Tabs don't appear with JDK7 Synth based LaF, different from Java 5/6 Reviewed-by: alexp !

Re: Swing Dev [7u4] Review request for 7154480: [macosx] Not all popup menu items are visible

On 3/26/12 17:04, Artem Ananiev wrote: The proposed fix implies the problem is only observed if no security manager is installed, is that correct? In that case, the fix looks fine... On 3/24/2012 1:44 PM, Alexander Zuev wrote: Actually that was the behavior of popups till some time ago

Re: Swing Dev [8] Review request for 7169111 Unreadable menu bar with Ambiance theme in GTK LF

Looks fine to me. With best regards, Alexander Zuev 26.06.2012, в 18:29, Pavel Porvatov pavel.porva...@oracle.com написал(а): Hello, Please review a fix for the following issue: 7169111 Unreadable menu bar with Ambiance theme in GTK LF http://bugs.sun.com/bugdatabase/view_bug.do?bug_id

Swing Dev [8] Please teview fix for 7600365: Create a test for https://jbs.oracle.com/bugs/browse/JDK-8000286

Please review my test for CR 7600365: Create a test for https://jbs.oracle.com/bugs/browse/JDK-8000286 The new regression test can be found at http://cr.openjdk.java.net/~kizune/7600365/webrev.00/ Test description is available only at https://jbs.oracle.com/bugs/browse/INTJDK-7600365 because

Swing Dev [8] Please review fix for 8003273: Missing testcase for 7171812

Please review my test for CR 8003273: Missing testcase for 7171812 The new regression test can be found at http://cr.openjdk.java.net/~kizune/8003273/webrev.00/ Bug description is available at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003273 With best regards, Alex

Re: RFR: 8253977: More memory leaks in client-libs on macOS

On Mon, 5 Oct 2020 19:49:43 GMT, Sergey Bylokhov wrote: > While working on the JDK-8240709 I have found that the test created for > JDK-8134947 (currently executed on macOS only) > can fail due to memory leaks(more often if change it to be stricter). See my > comments inline. Looks good.

Re: RFR: 8254085: javax/swing/text/Caret/TestCaretPositionJTextPane.java failed with "RuntimeException: Wrong caret position"

I did that and i did a full sanity tier3 run - both showed no problem with the test. I will put job URLs into the bug comments. On 10/17/2020 6:40 AM, Prasanta Sadhukhan wrote: On Sat, 17 Oct 2020 11:16:41 GMT, Alexander Zuev wrote: Hi Alex, With this modification, it passes even without

Re: RFR: 8254085: javax/swing/text/Caret/TestCaretPositionJTextPane.java failed with "RuntimeException: Wrong caret position"

Fixed. Please check new version. On 10/17/2020 3:09 AM, Prasanta Sadhukhan wrote: On Sat, 17 Oct 2020 09:38:28 GMT, Alexander Zuev wrote: Please review fix for the test issue. This test fails on machines with low display resolution. Limiting of the length of the line to 30 characters

RFR: 8254085: javax/swing/text/Caret/TestCaretPositionJTextPane.java failed with "RuntimeException: Wrong caret position"

Please review fix for the test issue. This test fails on machines with low display resolution. Limiting of the length of the line to 30 characters prevents it from wrapping the line for a second time which fixes the problem. I tested solution on different modes from 1024x768 to 3840x2160.

Re: RFR: 8254085: javax/swing/text/Caret/TestCaretPositionJTextPane.java failed with "RuntimeException: Wrong caret position" [v2]

odes from 1024x768 to 3840x2160. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Updated test so it does not pass without the fix for initial issue. Checked that it fails without the fix on all resolutions and passes with fix

Re: RFR: 8254085: javax/swing/text/Caret/TestCaretPositionJTextPane.java failed with "RuntimeException: Wrong caret position"

On Sat, 17 Oct 2020 10:06:38 GMT, Prasanta Sadhukhan wrote: > Hi Alex, > With this modification, it passes even without the fix for JDK-8232243 Fixed. By shifting click position left i'm avoiding clicking an empty space on low resolution displays and test passes with fix and fails without it.

Integrated: 8254085: javax/swing/text/Caret/TestCaretPositionJTextPane.java failed with "RuntimeException: Wrong caret position"

On Sat, 17 Oct 2020 09:38:28 GMT, Alexander Zuev wrote: > Please review fix for the test issue. This test fails on machines with low > display resolution. > Limiting of the length of the line to 30 characters prevents it from wrapping > the line > for a second time which fixes

Re: RFR: 8253980: javax/swing/plaf/synth/7158712/bug7158712.java fails on windows

On Mon, 5 Oct 2020 08:11:10 GMT, Prasanta Sadhukhan wrote: > This test was seen to be failing in mach5 hidpi system on windows. > The test actually checks for the fact that popup size should be 10 pixels > wider than the comboBox width and the popup > should overlap the comboBox by 5 pixels

Re: RFR: 8252194: Add automated test for fix done in JDK-8218469

Hi Pankaj,   in your test you have both * @requires (os.family == "linux") and if (!System.getProperty("os.name").startsWith("Linux")) { System.out.println("This test is meant for Linux platform only"); return; } Isn't it a little bit overkill?

Re: RFR: 8252194: Add automated test for fix done in JDK-8218469

On Sun, 27 Sep 2020 16:44:12 GMT, Pankaj Bansal wrote: > Under JDK-8218469, fix was made to correct the rendering of JSlider as the > Slider knob/head was not being rendered at > all. The reason was that gtk3 changed the way styles are used. No automated > test was written to verify the

RFR: 8182043: Access to Windows Large Icons

Moving review from Mercurial. See https://mail.openjdk.java.net/pipermail/awt-dev/2020-August/016078.html for previous iteration. - Commit messages: - emoved whitespaces from test - 8182043: Access to Windows Large Icons Changes: https://git.openjdk.java.net/jdk/pull/380/files

Re: RFR: 8255365: Problem list failing client manual tests [v8]

On Mon, 26 Oct 2020 16:20:31 GMT, Phil Race wrote: >> Problem list failing client manual jtreg tests. > > Phil Race has updated the pull request incrementally with one additional > commit since the last revision: > > 8255365: Problem list failing client manual tests Marked as reviewed by

Re: RFR JDK-8245785: javax.swing.JTabbedPane cannot be deserialized

Looks good now. /Alex On 7/15/2020 6:26 AM, Prasanta Sadhukhan wrote: On 14-Jul-20 7:41 PM, Prasanta Sadhukhan wrote: On 13-Jul-20 8:07 PM, Philip Race wrote: The regression test needs some clean up. It seems to be a copy+paste of the submitter's test case including the comment in German

Re: RFR: 8239137: JAWS does not always announce the value of JSliders in JColorChooser

Looks Ok to me. On 7/19/20 21:28, Pankaj Bansal wrote: Hi All, Please review the following fix for jdk16. Bug : https://bugs.openjdk.java.net/browse/JDK-8239137 webrev: http://cr.openjdk.java.net/~pbansal/8239137/webrev02/ Issue:

Re: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated

Fix looks good. Approved. On 10-Jun-20 0:09, Sergey Bylokhov wrote: On 6/8/20 10:55 am, Alexander Zuev wrote: Hi Sergey,    I see that in show() you have removed specific workaround for Solaris. I guess this is justified but shouldn't we put some comments that will prevent backporting

Re: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated

Hi Sergey,   I see that in show() you have removed specific workaround for Solaris. I guess this is justified but shouldn't we put some comments that will prevent backporting this fix to the version where Solaris support is still relevant?   Otherwise fix looks good. /Alex

Re: RFR 8245668:closed test javax/swing/JComboBox/4765319/bug4765319.java fails on windows

Hi Prasanta,   fix looks fine to me. /Alex -- > Hi All, > > Please review a fix for an issue seen whereby VK_ENTER is not handled when popup is visible for a comboBox. > > This issue is regressed because of the JDK-8067986 fix where a check is done upfront whether to accept this key

Re: [jdk16] RFR: 8259237: Demo selection changes with left/right arrow key. No need to press space for selection. [v3]

On Mon, 11 Jan 2021 13:30:15 GMT, Pankaj Bansal wrote: >> Please review a fix for jdk16 >> >> Issue: In SwingSet2, if the user navigates through the demos, the demo gets >> selected/starts on pressing left/right key only. There is no need to press >> the "space" key. Earlier, on pressing the

Re: [jdk16] RFR: 8259237: Demo selection changes with left/right arrow key. No need to press space for selection. [v2]

On Mon, 11 Jan 2021 08:20:39 GMT, Prasanta Sadhukhan wrote: >> Pankaj Bansal has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove duplicate call to remove listener > > I guess you did not run jtreg job with latest problemlist as it

Re: RFR: 8196100: javax/swing/text/JTextComponent/5074573/bug5074573.java fails

On Wed, 25 Nov 2020 00:15:11 GMT, Sergey Bylokhov wrote: > Here is a fix for one of the annoying bug, which causes random test failures > in the CI. > > We have a method Robot.waitForIdle(), which supposed to wait until the java > and the native queue stabilized. The common use case is to

Re: RFR: 8196100: javax/swing/text/JTextComponent/5074573/bug5074573.java fails [v2]

On Thu, 26 Nov 2020 04:52:17 GMT, Sergey Bylokhov wrote: >> Here is a fix for one of the annoying bug, which causes random test failures >> in the CI. >> >> We have a method Robot.waitForIdle(), which supposed to wait until the java >> and the native queue stabilized. The common use case is

Withdrawn: 8182043: Access to Windows Large Icons

On Mon, 28 Sep 2020 15:20:33 GMT, Alexander Zuev wrote: > Moving review from Mercurial. See > https://mail.openjdk.java.net/pipermail/awt-dev/2020-August/016078.html for > previous iteration. This pull request has been closed without being integrated. -

Re: [jdk16] RFR: 8258373: Update the text handling in the JPasswordField

On Wed, 16 Dec 2020 20:35:04 GMT, Sergey Bylokhov wrote: > - The JTextComponent.setText() is overidden in the JPasswordField to make the > "text" property non-"bound" in the JPasswordField, same as in the > JTextComponent > - The new implementation of setText() clean an internal data storage

Re: RFR: 4907798: MEMORY LEAK: javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper [v2]

On Mon, 9 Nov 2020 18:08:57 GMT, Sergey Bylokhov wrote: >> We do call ninstall() at the beginning of the method but it does not resolve >> the issue. > > I meant this code at the start of the method: > `if (!(UIManager.getLookAndFeel() instanceof BasicLookAndFeel)) { >

Re: RFR: 8211999: Window positioning bugs due to overlapping GraphicsDevice bounds (Windows/HiDPI) [v4]

On Wed, 28 Oct 2020 23:46:55 GMT, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk. >> >> Old review request: >> https://mail.openjdk.java.net/pipermail/awt-dev/2020-July/015991.html >> >> >> (Note: the fix use API available since Windows 8.1: WM_DPICHANGED, but it >> should

Integrated: 4907798: MEMORY LEAK: javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper

On Tue, 3 Nov 2020 10:32:01 GMT, Alexander Zuev wrote: > 4907798: MEMORY LEAK: > javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper This pull request has now been integrated. Changeset: ed615e3c Author:Alexander Zuev URL: https://git.openjdk.java.net/jdk/commit/ed

Re: RFR: 4907798: MEMORY LEAK: javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper [v2]

On Tue, 3 Nov 2020 18:41:20 GMT, Sergey Bylokhov wrote: >> Alexander Zuev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Test case made multiplatform and testing all the LaF's > &

Re: RFR: 4907798: MEMORY LEAK: javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper [v2]

On Tue, 3 Nov 2020 16:44:36 GMT, Prasanta Sadhukhan wrote: > I think even if the fix is in windows, there's no harm in making the test > platform agnostic and let it run for all platforms. Done. - PR: https://git.openjdk.java.net/jdk/pull/1035

Withdrawn: 4907798: MEMORY LEAK: javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper

On Tue, 3 Nov 2020 10:32:01 GMT, Alexander Zuev wrote: > 4907798: MEMORY LEAK: > javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/1035

Re: RFR: 4907798: MEMORY LEAK: javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper [v2]

> 4907798: MEMORY LEAK: > javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Test case made multiplatform and testing all the LaF's - Changes: - all:

Re: RFR: 4907798: MEMORY LEAK: javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper [v2]

On Tue, 10 Nov 2020 02:48:19 GMT, Sergey Bylokhov wrote: >> The code block here with uninstall is called if currently installed LAF is >> not derived from BasicLAF in which case we will not have this problem in the >> first place - the only place where we are setting menuInputMap variable is

RFR: 4907798: MEMORY LEAK: javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper

4907798: MEMORY LEAK: javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper - Commit messages: - 4907798: MEMORY LEAK: javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper - Merge pull request #1 from openjdk/master Changes:

Re: RFR: 8211999: Window positioning bugs due to overlapping GraphicsDevice bounds (Windows/HiDPI)

On Fri, 2 Oct 2020 16:47:37 GMT, Victor Dyakov wrote: >> @prsadhuk can you review this? > > @prrace Can you review this? I'm trying to test these changes but i have weird problems with mouse event coordinate translation. For example - i have two displays side by side with some vertical shift

Re: RFR: 8240709: Enable javax/swing/UI/UnninstallUIMemoryLeaks/UnninstallUIMemoryLeaks.java on all L

On Sun, 11 Oct 2020 21:26:06 GMT, Sergey Bylokhov wrote: > Fix for various memory leaks in Nimbus and Motif L, see comments inline. Looks ok. - Marked as reviewed by kizune (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/595

Integrated: 8258643: javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button"

On Mon, 4 Jan 2021 10:07:08 GMT, Alexander Zuev wrote: > 8258643: javax/swing/JComponent/7154030/bug7154030.java failed with > "Exception: Failed to hide opaque button" This pull request has now been integrated. Changeset: fc3b45c0 Author: Alexander Zuev

Integrated: 8259650: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"

On Sun, 17 Jan 2021 09:26:52 GMT, Alexander Zuev wrote: > 8259650: javax/swing/JComponent/7154030/bug7154030.java still fails with > "Exception: Failed to hide opaque button" This pull request has now been integrated. Changeset: 917f7e9a Author: Alexander Zuev

[jdk16] RFR: 8258643: [TESTBUG] javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button"

Backport from mainline. - Commit messages: - 8258643: [TESTBUG] javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button" Changes: https://git.openjdk.java.net/jdk16/pull/119/files Webrev:

Re: [jdk16] RFR: 8258643: [TESTBUG] javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button" [v2]

> Backport from mainline. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Added 1s delay before taking the first screenshot to give slow systems enough time to finish painting. - Changes: - all: ht

RFR: 8259650: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"

8259650: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button" - Commit messages: - 8259650: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button" - Merge remote-tracking

[jdk16] Integrated: 8258643: [TESTBUG] javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button"

On Wed, 13 Jan 2021 22:26:47 GMT, Alexander Zuev wrote: > Backport from mainline. This pull request has now been integrated. Changeset: bb0821eb Author: Alexander Zuev URL: https://git.openjdk.java.net/jdk16/commit/bb0821eb Stats: 13 lines in 1 file changed: 2 ins; 5 del; 6

Re: [jdk16] RFR: 8258643: [TESTBUG] javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button"

On Fri, 15 Jan 2021 06:12:15 GMT, Sergey Bylokhov wrote: > Looks like this test still fails in the mainline as well: > https://bugs.openjdk.java.net/browse/JDK-8259650 Yes but the reason is different. Now it seems like component's screenshot taken when component is not fully painted. Looking

RFR: 8258643: javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button"

8258643: javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button" - Commit messages: - 8258643: javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button" - Merge pull request #7 from

Re: RFR: 8258643: javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button" [v2]

> 8258643: javax/swing/JComponent/7154030/bug7154030.java failed with > "Exception: Failed to hide opaque button" Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Imports fixed. - Changes

Re: RFR: 8258643: javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button" [v2]

On Mon, 4 Jan 2021 11:22:37 GMT, Sergey Bylokhov wrote: >> test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 105: >> >>> 103: locy = bounds.y + insets.top; >>> 104: frw = bounds.width - insets.left - insets.right; >>> 105: frh = bounds.height -

Re: RFR: 8216358: [accessibility] [macos] The focus is invisible when tab to "Image Radio Buttons" and "Image CheckBoxes"

On Wed, 3 Feb 2021 18:50:34 GMT, Alexander Zuev wrote: > 8216358: [accessibility] [macos] The focus is invisible when tab to "Image > Radio Buttons" and "Image CheckBoxes" This is how radio button group with custom icons looks without the fix. The focus is on the

RFR: 8216358: [accessibility] [macos] The focus is invisible when tab to "Image Radio Buttons" and "Image CheckBoxes"

8216358: [accessibility] [macos] The focus is invisible when tab to "Image Radio Buttons" and "Image CheckBoxes" - Commit messages: - 8216358: [accessibility] [macos] The focus is invisible when tab to "Image Radio Buttons" and "Image CheckBoxes" Changes:

Re: RFR: 8216358: [accessibility] [macos] The focus is invisible when tab to "Image Radio Buttons" and "Image CheckBoxes" [v2]

> 8216358: [accessibility] [macos] The focus is invisible when tab to "Image > Radio Buttons" and "Image CheckBoxes" Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Test simplification.

Re: RFR: 8216358: [accessibility] [macos] The focus is invisible when tab to "Image Radio Buttons" and "Image CheckBoxes" [v2]

On Thu, 4 Feb 2021 01:09:42 GMT, Sergey Bylokhov wrote: >> test/jdk/javax/swing/JCheckBox/ImageCheckboxFocus/ImageCheckboxTest.java >> line 68: >> >>> 66: public void performTest() throws Exception { >>> 67: try { >>> 68: BufferedImage imageFocus1 = null; >> >>

Re: RFR: 8216358: [accessibility] [macos] The focus is invisible when tab to "Image Radio Buttons" and "Image CheckBoxes" [v2]

On Wed, 3 Feb 2021 23:52:24 GMT, Sergey Bylokhov wrote: >> Alexander Zuev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Test simplification. > > src/java.desktop/macosx/classes/com/apple/laf/AquaBu

[jdk17] RFR: 8268775: Password is being converted to String in AccessibleJPasswordField

8268775: Password is being converted to String in AccessibleJPasswordField - Commit messages: - 8268775: Password is being converted to String in AccessibleJPasswordField Changes: https://git.openjdk.java.net/jdk17/pull/127/files Webrev:

Re: [jdk17] RFR: 8268775: Password is being converted to String in AccessibleJPasswordField

On Wed, 23 Jun 2021 17:50:51 GMT, Phil Race wrote: >> 8268775: Password is being converted to String in AccessibleJPasswordField > > src/java.desktop/share/classes/javax/swing/JPasswordField.java line 514: > >> 512: public String getAtIndex(int part, int index) { >> 513: if

Re: [jdk17] RFR: 8268775: Password is being converted to String in AccessibleJPasswordField

On Wed, 23 Jun 2021 17:20:27 GMT, Alexander Zuev wrote: > 8268775: Password is being converted to String in AccessibleJPasswordField The problem here is that if someone uses the accessibility methods on JPasswordField it will lead to unencrypted password being stored in the local Str

Re: RFR: 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS [v4]

On Mon, 10 May 2021 21:47:31 GMT, Sergey Bylokhov wrote: >> Alexander Zuev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Small fixes > > test/jdk/javax/swing/JPopupMenu/7156657/bug7156657.java line 113:

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

> 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 Win32ShellFolder2.getSystemIcon scaling issue - Changes: - all: ht

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

> 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 - Changes: - all: https://git.openjdk.java.net/jdk/pull/2875/files - new: ht

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

On Sun, 16 May 2021 18:49:24 GMT, Alexander Zvegintsev wrote: >> Alexander Zuev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Slight change of wording in javadoc >> Fixed Win32ShellFolder2.getSy

Re: RFR: 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS [v4]

> Fixed popup position taking into account its offset > Added a lot of screenshots taking to better understand failures should they > happen down the line Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Sm

Re: RFR: 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS [v2]

On Sat, 8 May 2021 06:43:44 GMT, Prasanta Sadhukhan wrote: > I will still urge to bring the frame to middle to be more safe. Ok, not that it makes any difference so there you go. > BTW, greenFrame and redFrame screencapture are needed only in failure case so > I guess those should be called

Integrated: 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS

On Mon, 3 May 2021 19:30:07 GMT, Alexander Zuev wrote: > Fixed popup position taking into account its offset > Added a lot of screenshots taking to better understand failures should they > happen down the line This pull request has now been integrated. Changeset: 9b769550 Author:

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

On Fri, 30 Apr 2021 20:23:21 GMT, Alexey Ivanov wrote: >> Alexander Zuev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp >>

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

On Fri, 30 Apr 2021 20:54:01 GMT, Alexey Ivanov wrote: >> src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line >> 1146: >> >>> 1144: } >>> 1145: Map multiResolutionIcon = new HashMap<>(); >>> 1146: int start = size > MAX_QUALITY_ICON ?

Re: RFR: 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS [v2]

On Fri, 7 May 2021 16:00:37 GMT, Prasanta Sadhukhan wrote: > I'm not sure about this change...Maybe changing frame location from (0,0) at > l192 to middle of screen though selLocationRelativeTo() may be enough to make > the test more stable in CI systems. The problem here is not only in

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

On Fri, 30 Apr 2021 20:48:21 GMT, Alexey Ivanov wrote: >> Getting smaller icon is relevant in the case of the scaling. I do not think >> refactoring image caches from icons to multiresolution images will make code >> much cleaner - at the end we will have to extract images from the >>

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

> Fix updated after first round of review. Alexander Zuev 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 five additional commits since the l

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

On Fri, 30 Apr 2021 20:50:53 GMT, Alexey Ivanov wrote: >> test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 64: >> >>> 62: } >>> 63: >>> 64: if (icon.getIconWidth() != size) { >> >> Does it make sense to check that the icon is a multi-resolution

Re: RFR: 8266249: javax/swing/JPopupMenu/7156657/bug7156657.java fails on macOS [v3]

> Fixed popup position taking into account its offset > Added a lot of screenshots taking to better understand failures should they > happen down the line Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Simplify pop

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

On Fri, 30 Apr 2021 20:34:01 GMT, Alexey Ivanov wrote: >> Alexander Zuev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp >>

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

> Fix updated after first round of review. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Fixed documentation based on CSR review feedback - Changes: - all: https://git.openjdk.java.net/jdk/pull/2875/files -

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

On Fri, 21 May 2021 03:21:19 GMT, Sergey Bylokhov wrote: >> The JFileChooser supports the libraries since it allows navigation inside >> them. It is done via ShellFolder which extends the file class. The >> FileSystemView feeds the JFileChooser by the data, so it may returns >> "non-file"

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

On Fri, 21 May 2021 05:42:46 GMT, Sergey Bylokhov wrote: > It is accessible from the "JFileChooser" drop-down menu. On my system, the > Libraries at that drop down menu contain "GIT", "Documents", "Music". > https://docs.microsoft.com/en-us/windows/client-management/windows-libraries > >

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

> Fix updated after first round of review. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Specification of getSystemIcon reworded to get rid of the non-public class reference and to better describe some cornor ca

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

On Thu, 20 May 2021 22:37:08 GMT, Sergey Bylokhov wrote: > I did not get how you will be able to force use MRI later since this method > is implemented as a return icon. So this choice should be made before > integration. I am not going to force MRI usage - i am assuming that there might be

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

On Thu, 20 May 2021 22:38:48 GMT, Sergey Bylokhov wrote: > But this is shared code, which has a specification it should work everywhere, > so even if on Linux and macOS it is not implemented in the best way it should > return something. The stuff that is returned by the common code is already

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

On Thu, 20 May 2021 19:35:57 GMT, Phil Race wrote: > Really I would need to see what the actual delta ends up being to be sure for > this case. I have updated the method documentation. Could you please take a look before i finalized the CSR again? I am really trying to push this functionality

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

On Thu, 20 May 2021 07:47:02 GMT, Sergey Bylokhov wrote: >> Alexander Zuev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Empty tag before @implSpec causes warning during javadoc generation > > src/ja

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

On Thu, 20 May 2021 08:18:02 GMT, Sergey Bylokhov wrote: >>> What are the "virtual pixels"? I remember we refer to something similar by >>> the point in the "user space coordinate system" Or probably we use the >>> virtual pixels somewhere? >> >> It is to say that the sizes are given in the

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

> Fix updated after first round of review. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Empty tag before @implSpec causes warning during javadoc generation - Changes: - all: https://git.openjdk.java.net/jdk/p

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

On Thu, 20 May 2021 07:46:28 GMT, Sergey Bylokhov wrote: > What are the "virtual pixels"? I remember we refer to something similar by > the point in the "user space coordinate system" Or probably we use the > virtual pixels somewhere? It is to say that the sizes are given in the same pixels

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

On Thu, 20 May 2021 08:25:25 GMT, Sergey Bylokhov wrote: > The @implSpec is part of the specification, it is different from the > @implNote, no? >

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

On Fri, 14 May 2021 13:30:13 GMT, Alexey Ivanov wrote: >> Alexander Zuev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Make getShell32Icon method return multi-resolition image in case of >> requested

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

On Fri, 14 May 2021 13:41:31 GMT, Alexey Ivanov wrote: >> I see - but still it has to be solved in the getShell32Icon method - which >> i'm going to do in a moment. > > `Win32ShellFolder2.getSystemIcon` is still affected, the return value should > be wrapped into MR-icon if its size is not

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

On Tue, 11 May 2021 10:53:06 GMT, Alexey Ivanov wrote: >> Alexander Zuev 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 contai

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

On Tue, 11 May 2021 10:07:30 GMT, Alexey Ivanov wrote: >> Alexander Zuev 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 contai

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

> Fix updated after first round of review. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Slightly changing javadoc wording Removing unnecessary boxing of int Releasing the pIcon in native code properly - Chan

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

On Tue, 11 May 2021 20:01:37 GMT, Alexey Ivanov wrote: >> Wherever it is necessary down the line we are wrapping the result in >> multi-resolution and if we wrap it here too we will have multi-resolution >> icon that contains multi-resolution images as a resolution variant. >> Unfortunately

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

> Fix updated after first round of review. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Make getShell32Icon method return multi-resolition image in case of requested icon size and actual icon size misma

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

On Thu, 20 May 2021 16:06:37 GMT, Sergey Bylokhov wrote: >> Are we sure that all possible paths can be pointed by the file object? >> Especially some "Windows Libraries" which are accessed by the shell folder? > > Later we say that this method returns null for non-existed files. is it > always

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

On Thu, 20 May 2021 16:43:05 GMT, Alexander Zuev wrote: >> Later we say that this method returns null for non-existed files. is it >> always correct? I am not sure that the file created for the library report >> true for the exists() method; DId we test this usecase?

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

On Thu, 20 May 2021 16:13:41 GMT, Sergey Bylokhov wrote: >> My point was that the implspec is a normative specification and we cannot >> refer to non-public classes in that documentation. > > As for the example on Linux, how it will work for different sizes? >Icon icon1 =

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

On Thu, 20 May 2021 16:53:06 GMT, Alexander Zuev wrote: >> As for the example on Linux, how it will work for different sizes? >>Icon icon1 = fsv.getSystemIcon(new File("."), 16); >>Icon icon2 = fsv.getSystemIcon(new File("."), 32); >> Will t

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

On Thu, 20 May 2021 17:29:55 GMT, Sergey Bylokhov wrote: > Here I am not talking about specification, I am talking about the usage of > it, is the instanceof+cast is helpful? It is necessary until all the consequences of always returning of MRI is extensively tested on all the supported

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

On Thu, 20 May 2021 15:57:04 GMT, Sergey Bylokhov wrote: > This is to describe one of my questions above, is this instanceof+cast cannot > be improved? Why we cannot always wrap the data in the MRI and if we have > only one icon return the MRI with one resolution? No because in specification

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

On Thu, 20 May 2021 16:14:42 GMT, Sergey Bylokhov wrote: > BTW this is why I recommended filing a CSR after the fix is fully discussed > and agreed upon. The CSR was filed almost five years ago. - PR: https://git.openjdk.java.net/jdk/pull/2875

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

On Thu, 20 May 2021 16:09:14 GMT, Sergey Bylokhov wrote: > Other than using "explorer" what prevents us to run this test on other > platforms? Because right now it makes no sense? The functionality we are testing is implemented on Windows only. Once we extend it to other platforms we might

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

On Thu, 20 May 2021 17:33:08 GMT, Sergey Bylokhov wrote: > But it is still part of the specification unlike implnote/apinote I think you can suggest usage of the implNote here - i am going from the initial description of the reason implSpec in the JEP saying that implementation and logic of

  1   2   3   >