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

2021-05-26 Thread Sergey Bylokhov
On Fri, 21 May 2021 19:37:19 GMT, Alexander Zuev wrote: >> Didn't you answer your question already? If `FileSystemView.getRoots()` >> returns Desktop in Windows shell namespace. Otherwise, I don't know a way to >> get a reference to a *virtual* folder in Windows shell namespace which >>

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

2021-05-26 Thread Sergey Bylokhov
On Wed, 26 May 2021 16:52:38 GMT, Alexander Zuev wrote: >> Fix updated after first round of review. > > Alexander Zuev has updated the pull request incrementally with two additional > commits since the last revision: > > - Fixed small errors >Adjustments in the test > - Grammar fix in

Re: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec [v5]

2021-05-21 Thread Sergey Bylokhov
On Thu, 1 Apr 2021 16:19:48 GMT, Prasanta Sadhukhan wrote: >> A public overriding method >> JMenu.setComponentOrientation(java.awt.ComponentOrientation) >> has no spec. >> Added spec for the method. > > Prasanta Sadhukhan has updated the pull request incrementally with one > additional commit

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

2021-05-21 Thread Sergey Bylokhov
On Fri, 21 May 2021 01:11:38 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. >> >> T

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

2021-05-21 Thread Sergey Bylokhov
On Fri, 21 May 2021 06:32:02 GMT, Alexander Zuev 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 [v7]

2021-05-20 Thread Sergey Bylokhov
On Fri, 21 May 2021 04:15:41 GMT, Alexander Zuev wrote: >> Maybe we can test this case by just reusing this method where the >> "sf.getIcon(largeicon)" previously used in the WindowsPlacesBar class? That >> old method has the special code for "folder.isLibrary()" so I assume it >> supported

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

2021-05-20 Thread Sergey Bylokhov
On Fri, 21 May 2021 02:45:15 GMT, Sergey Bylokhov wrote: >> No, libraries are not supported. >> >> I see no contradiction here: `JFileChooser` uses Windows Shell API to >> enumerate objects and navigate the shell namespace. But it does not return >> non-file ob

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

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 18:51:54 GMT, Alexey Ivanov wrote: >> So the libraries are not supported? I doubt since JFileChooser should >> support them, and supports of it is one of the reasons why we use shell >> folder to iterate the folders and do not use the javaio. > > No, libraries are not

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

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 23:03:02 GMT, Alexander Zuev 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. > >> But this is shared code, which has a specification

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

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 22:59:43 GMT, Alexander Zuev 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 did not get how you will be able to force use MRI later since

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

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 19:25:38 GMT, Alexander Zuev wrote: >> Here I am not talking about specification, I am talking about the usage of >> it, is the instanceof+cast is helpful? It does not look good, why we cannot >> always return MRI? > >> Here I am not talking about specification, I am

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

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 18:49:53 GMT, Alexander Zuev wrote: >> test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 27: >> >>> 25: * @test >>> 26: * @bug 8182043 >>> 27: * @requires os.family == "windows" >> >> Other than using "explorer" what prevents us to run this test

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

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 16:45:35 GMT, Alexander Zuev wrote: >> We do not test for that in the regression test but i did tested it manually >> and we do return null for the non-existed files. I tested it on non-windows >> platform too. We still return null. > >> Are we sure that all possible paths

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

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 17:25:33 GMT, Alexander Zuev wrote: >> test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 72: >> >>> 70: if (icon.getImage() instanceof MultiResolutionImage) { >>> 71: MultiResolutionImage mri = (MultiResolutionImage) >>>

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

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 16:58:36 GMT, Alexander Zuev wrote: >> No they will have the same size. That's why the broad wording is used that >> we take a requested size into consideration but we will return the best >> possible icon we can get and we do not guarantee that the icon size will >>

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

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 14:55:06 GMT, Alexey Ivanov wrote: >> The CSR is already approved and changing specification at this point will >> require to roll it back to draft and then going trough the approval process >> again which in turn risks this change not to make it in the upcoming LTS >>

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

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 07:30:00 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: > > Empty tag before @implSpec causes warning during javadoc generation

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

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 16:01:32 GMT, Sergey Bylokhov wrote: >>> The @implSpec is part of the specification, it is different from the >>> @implNote, no? >>> https://bugs.openjdk.java.net/browse/JDK-8266541?focusedCommentId=14419988=com.atlassian.jira.plugin.system.issuet

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

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 07:30:00 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: > > Empty tag before @implSpec causes warning during javadoc generation

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

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 10:36:39 GMT, Alexander Zuev wrote: >> The @implSpec is part of the specification, it is different from the >> @implNote, no? >>

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

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 07:40:35 GMT, Sergey Bylokhov wrote: >> Good catch! Yes, fixed both here and in CSR. > > 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? Late

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

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 08:13:21 GMT, Alexander Zuev wrote: >> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java >> line 272: >> >>> 270: * returned is a multi-resolution icon image, >>> 271: * which allows better support for High DPI environments >>> 272: *

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

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 08:07:48 GMT, Alexander Zuev wrote: >> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java >> line 275: >> >>> 273: * >>> 274: * @param f a {@code File} object >>> 275: * @param size width and height of the icon in virtual pixels >> >>

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

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 07:30:00 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: > > Empty tag before @implSpec causes warning during javadoc generation

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

2021-05-20 Thread Sergey Bylokhov
On Mon, 17 May 2021 05:08:13 GMT, Alexander Zuev wrote: >> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java >> line 271: >> >>> 269: * Example: >>> 270: * FileSystemView fsv = FileSystemView.getFileSystemView(); >>> 271: * Icon icon =

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

2021-05-10 Thread Sergey Bylokhov
On Sat, 8 May 2021 16:01:28 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 > > Alexander Zuev has updated the pull request incrementally with one additional

Re: RFR: 8265528: Specification of BasicSplitPaneDivider::getMinimumSize, getPreferredSize doesn't match with its behavior.

2021-05-06 Thread Sergey Bylokhov
On Thu, 6 May 2021 05:14:42 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java >> line 309: >> >>> 307: * >>> 308: * @return a {@code Dimension} object containing the preferred >>> size of >>> 309: *

Re: RFR: 8265528: Specification of BasicSplitPaneDivider::getMinimumSize, getPreferredSize doesn't match with its behavior.

2021-05-05 Thread Sergey Bylokhov
On Wed, 5 May 2021 07:01:34 GMT, Prasanta Sadhukhan wrote: > The current specification of these 2 methods > api/java.desktop/javax/swing/plaf/basic/BasicSplitPaneDivider.html#getPreferredSize(). > and > api/java.desktop/javax/swing/plaf/basic/BasicSplitPaneDivider.html#getMinimumSize() > does

Re: RFR: 8264950: Set opaque for JTooltip in config file of NimbusLookAndFeel

2021-05-03 Thread Sergey Bylokhov
On Mon, 3 May 2021 08:54:19 GMT, Tejpal Rebari wrote: > Set the opaque property for JToolTip in config file (skin.laf) of > NimbusLookAndFeel instead of setting up in the SynthToolTipUI. > This is related to the discussion on PR > https://github.com/openjdk/jdk/pull/3167. Marked as reviewed

Re: RFR: 8163367: Test javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java javax/swing/JComboBox/8033069/bug8033069ScrollBar.java fails intermittently

2021-04-25 Thread Sergey Bylokhov
On Sun, 25 Apr 2021 16:27:46 GMT, Pankaj Bansal wrote: > The tests a javax/swing/JComboBox/8033069/bug8033069ScrollBar.java and > javax/swing/JComboBox/8033069/bug8033069NoScrollBar.java fails > intermittently. The tests have a few problems which could cause this > behaviour and the are being

Re: RFR: 8171381: [TEST_BUG] [macos] javax/swing/JPopupMenu/7156657/bug7156657.java fails on OS X [v2]

2021-04-21 Thread Sergey Bylokhov
On Wed, 21 Apr 2021 22:39:52 GMT, Alexander Zuev wrote: >> Replaces usage of SunToolkit.realSync() with Robot.waitForIdle() > > Alexander Zuev has updated the pull request incrementally with one additional > commit since the last revision: > > Remove modules clause Marked as reviewed by

Re: RFR: 8171381: [TEST_BUG] [macos] javax/swing/JPopupMenu/7156657/bug7156657.java fails on OS X

2021-04-21 Thread Sergey Bylokhov
On Wed, 21 Apr 2021 21:12:44 GMT, Alexander Zuev wrote: > It will not solve the problem as there is no problem as such. Ok, then please add this thing to the JBS. - PR: https://git.openjdk.java.net/jdk/pull/3606

Re: RFR: 8171381: [TEST_BUG] [macos] javax/swing/JPopupMenu/7156657/bug7156657.java fails on OS X

2021-04-21 Thread Sergey Bylokhov
On Wed, 21 Apr 2021 16:15:50 GMT, Alexander Zuev wrote: > Replaces usage of SunToolkit.realSync() with Robot.waitForIdle() test/jdk/javax/swing/JPopupMenu/7156657/bug7156657.java line 42: > 40: > 41: import sun.awt.SunToolkit; > 42: The "@modules java.desktop/sun.awt" should be removed as

Re: RFR: 8171381: [TEST_BUG] [macos] javax/swing/JPopupMenu/7156657/bug7156657.java fails on OS X

2021-04-21 Thread Sergey Bylokhov
On Wed, 21 Apr 2021 16:15:50 GMT, Alexander Zuev wrote: > Replaces usage of SunToolkit.realSync() with Robot.waitForIdle() The Robot.waitForIdle() is implemented via SunToolkit.realSync(), I am not sure how it might solve the problem. - PR:

Re: RFR: 8264398: BevelBorderUIResource​(int, Color, Color) and BevelBoder(int, Color, Color) spec should clarify about usage of highlight and shadow color [v6]

2021-04-12 Thread Sergey Bylokhov
On Mon, 12 Apr 2021 04:18:22 GMT, Prasanta Sadhukhan wrote: >> The current spec for >> javax/swing/plaf/BorderUIResource.BevelBorderUIResource.html(int,java.awt.Color,java.awt.Color) >> does not clearly specify the usage of color for hightlight and shadow as >> there are outer/inner

Re: RFR: 8264398: BevelBorderUIResource​(int, Color, Color) and BevelBoder(int, Color, Color) spec should clarify about usage of highlight and shadow color [v5]

2021-04-10 Thread Sergey Bylokhov
On Fri, 9 Apr 2021 03:20:43 GMT, Prasanta Sadhukhan wrote: >> The current spec for >> javax/swing/plaf/BorderUIResource.BevelBorderUIResource.html(int,java.awt.Color,java.awt.Color) >> does not clearly specify the usage of color for hightlight and shadow as >> there are outer/inner

Re: RFR: 8264398: BevelBorderUIResource​(int, Color, Color) and BevelBoder(int, Color, Color) spec should clarify about usage of highlight and shadow color [v3]

2021-04-08 Thread Sergey Bylokhov
On Thu, 8 Apr 2021 04:58:14 GMT, Prasanta Sadhukhan wrote: >> The current spec for >> javax/swing/plaf/BorderUIResource.BevelBorderUIResource.html(int,java.awt.Color,java.awt.Color) >> does not clearly specify the usage of color for hightlight and shadow as >> there are outer/inner

Re: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec [v5]

2021-04-07 Thread Sergey Bylokhov
On Thu, 8 Apr 2021 04:27:16 GMT, Prasanta Sadhukhan wrote: >>> The behavior is not a javadoc bug. If a method is overridden with no >>> specified change in behavior, the method will be documented in the "Methods >>> Declared In ..." list at the end of the main summary table. >> >> If it is

Re: RFR: 8264398: BevelBorderUIResource​(int, Color, Color) spec should mention that the passed colors are for highlightInner and shadowOuter props

2021-04-07 Thread Sergey Bylokhov
On Thu, 8 Apr 2021 04:31:12 GMT, Prasanta Sadhukhan wrote: > I don't think the spec is coped from BevelBorder...Yes, the spec is inspired > by how BevelBorder treates the shadow/highlight color! The BevelBorderUIResource is just a tagged wrapper on top of the BevelBorder, it does not provide

Re: RFR: 8264398: BevelBorderUIResource​(int, Color, Color) spec should mention that the passed colors are for highlightInner and shadowOuter props

2021-04-07 Thread Sergey Bylokhov
On Thu, 8 Apr 2021 04:20:16 GMT, Prasanta Sadhukhan wrote: > Not sure I understand...The change is still in BevelorderUIResource(int, > Color, Color) method so what should be changed in PR title? It should be Bevelorder as well, the class from where the spec is copied to the

Re: RFR: 8264398: BevelBorderUIResource​(int, Color, Color) spec should mention that the passed colors are for highlightInner and shadowOuter props

2021-04-07 Thread Sergey Bylokhov
On Thu, 8 Apr 2021 00:56:34 GMT, Sergey Bylokhov wrote: >> In this context and BevelBorder context, 'derived' is used for >> brighter/darker version of the same color and as per Color.brighter method >> https://github.com/openjdk/jdk/blob/master/src/java.desktop/shar

Re: RFR: 8264398: BevelBorderUIResource​(int, Color, Color) spec should mention that the passed colors are for highlightInner and shadowOuter props

2021-04-07 Thread Sergey Bylokhov
On Tue, 6 Apr 2021 12:31:00 GMT, Prasanta Sadhukhan wrote: >> Does 'derived' in javax.swing domain mean the color would be different, or >> 'equal color' also qualifies as 'derived' javax.swing? > > In this context and BevelBorder context, 'derived' is used for > brighter/darker version of

Re: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec [v5]

2021-04-07 Thread Sergey Bylokhov
On Thu, 8 Apr 2021 00:16:29 GMT, Jonathan Gibbons wrote: > The behavior is not a javadoc bug. If a method is overridden with no > specified change in behavior, the method will be documented in the "Methods > Declared In ..." list at the end of the main summary table. If it is not a bug it is

Re: RFR: 8262981: Create implementation for NSAccessibilitySlider protocol

2021-04-07 Thread Sergey Bylokhov
On Mon, 5 Apr 2021 18:47:25 GMT, Pankaj Bansal wrote: >> Ok, please file a similar bug for the windows platform. > > @mrserb @azuev-java Any other comments on this? Can you please look at the > CSR also? I have no additional comments. - PR:

Re: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec [v5]

2021-04-07 Thread Sergey Bylokhov
On Wed, 7 Apr 2021 03:32:35 GMT, Prasanta Sadhukhan wrote: > I dont see any update in JDK-8264217. Is this then considered to be a javadoc > bug? It does not matter is it a JavaDoc bug or feature. If it is a bug it will be fixed and spec will be returned for the current method. If it is an

Re: RFR: 8263907: Specification of CellRendererPane::paintComponent(..Rectangle) should clearly mention which method it delegates the call to [v2]

2021-04-07 Thread Sergey Bylokhov
On Wed, 7 Apr 2021 03:21:13 GMT, Prasanta Sadhukhan wrote: >> Specification for method >> javax/swing/CellRendererPane.html#paintComponent(java.awt.Graphics,java.awt.Component,java.awt.Container,java.awt.Rectangle) >> is not perfectly clear which method the call is delegated to. >> >> Updated

Re: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3]

2021-04-06 Thread Sergey Bylokhov
On Mon, 5 Apr 2021 17:45:33 GMT, Sergey Bylokhov wrote: >> I personally feel setting in code will be easier to maintain going forward >> than to go through property file settings. > > Then why we need this file at all? Now we will set the false value in the > config, and

Re: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3]

2021-04-05 Thread Sergey Bylokhov
On Mon, 5 Apr 2021 07:55:11 GMT, Prasanta Sadhukhan wrote: >> What is the difference from setting it via "skin.laf"? The "skin.laf" is >> converted to the NimbusDefaults during the build and these defaults are used >> by the NimbusLookAndFeel. > > I personally feel setting in code will be

Re: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3]

2021-04-05 Thread Sergey Bylokhov
On Mon, 5 Apr 2021 07:33:16 GMT, Tejpal Rebari wrote: >> I am not sure where you placed the code. I think it's need to be added after >> updateStyle() as updateStyle() uninstall the default and install for new >> style. >> protected void installDefaults(JComponent c) { >>

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

2021-04-04 Thread Sergey Bylokhov
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

Re: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v8]

2021-04-02 Thread Sergey Bylokhov
On Thu, 4 Mar 2021 05:50:18 GMT, Tejpal Rebari wrote: >> Please review the following fix for jdk17. >> In this fix i have deprecated and marked for removal following classes and >> methods >>public void intervalAdded(ListDataEvent e) >>public void intervalRemoved(ListDataEvent e) >>

Re: RFR: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic [v8]

2021-04-02 Thread Sergey Bylokhov
On Fri, 2 Apr 2021 22:34:59 GMT, Sergey Bylokhov wrote: >> Tejpal Rebari 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 contain

Re: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v3]

2021-04-02 Thread Sergey Bylokhov
On Thu, 1 Apr 2021 14:37:48 GMT, Tejpal Rebari wrote: >> Hi All, >> Please review the following fix for jdk17. >> >> Issue : LookAndFeel.installProperty(list, "opaque", false) is not able to >> set the opaque property for JList and JTable. >> LookAndFeel.installProperty calls the

Re: RFR: 8264526: javax/swing/text/html/parser/Parser/8078268/bug8078268.java timeout

2021-04-02 Thread Sergey Bylokhov
On Wed, 31 Mar 2021 16:23:23 GMT, Jie Fu wrote: > Hi all, > > I'd like to fix the timeout of > javax/swing/text/html/parser/Parser/8078268/bug8078268.java. > It seems to take about 6~7 seconds to run on some of our testing platforms. > But the timeout of the test is hard-coded as 5 seconds. >

Re: RFR: 8263907: Specification of CellRendererPane::paintComponent(..Rectangle) should clearly mention which method it delegates the call to

2021-04-01 Thread Sergey Bylokhov
On Tue, 23 Mar 2021 06:10:32 GMT, Prasanta Sadhukhan wrote: > Specification for method > javax/swing/CellRendererPane.html#paintComponent(java.awt.Graphics,java.awt.Component,java.awt.Container,java.awt.Rectangle) > is not perfectly clear which method the call is delegated to. > > Updated

Re: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec [v5]

2021-04-01 Thread Sergey Bylokhov
On Thu, 1 Apr 2021 16:14:14 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one >> additional commit since the last revision: >> >> javadoc change > > Marked as reviewed by aivanov (Reviewer). > This might have been overlooked. The overridden

Re: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec

2021-04-01 Thread Sergey Bylokhov
On Thu, 1 Apr 2021 15:29:34 GMT, Jonathan Gibbons wrote: >>> >>> Starting in JDK 10, the default behavior of the standard doclet was changed >>> so that if a method is just being overridden for implementation reasons, >>> and there is no change in the public spec or signature, then the method

Re: RFR: 8264428: Replace uses of StringBuffer with StringBuilder in java.desktop

2021-03-31 Thread Sergey Bylokhov
On Tue, 30 Mar 2021 12:39:15 GMT, Aleksey Shipilev wrote: >> Found by IntelliJ IDEA inspection `Java | Java language level migration aids >> | Java 5 | 'StringBuffer' may be 'StringBuilder'` >> As suggested in >> https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created >>

Re: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI [v2]

2021-03-31 Thread Sergey Bylokhov
On Thu, 25 Mar 2021 08:03:21 GMT, Tejpal Rebari wrote: >> Hi All, >> Please review the following fix for jdk17. >> >> Issue : LookAndFeel.installProperty(list, "opaque", false) is not able to >> set the opaque property for JList and JTable. >> LookAndFeel.installProperty calls the

Re: RFR: JDK-8263235 : sanity/client/SwingSet/src/ColorChooserDemoTest.java failed throwing java.lang.NoClassDefFoundError [v2]

2021-03-31 Thread Sergey Bylokhov
On Fri, 12 Mar 2021 14:39:23 GMT, Amresh Sahu wrote: >> Added @build org.jemmy2ext.JemmyExt. > > Amresh Sahu has updated the pull request incrementally with one additional > commit since the last revision: > > JDK-8263235:Added @build org.jemmy2ext.JemmyExt Marked as reviewed by serb

Re: RFR: 8262981: Create implementation for NSAccessibilitySlider protocol

2021-03-31 Thread Sergey Bylokhov
On Tue, 30 Mar 2021 09:46:45 GMT, Pankaj Bansal wrote: >>> It looks like the Dialog must have handled the keys as there are no special >>> keys mentioned for JAWS to interact with the component like the VO >> >> Did you check this list of hotkeys? >>

Integrated: 8264328: Broken license in javax/swing/JComboBox/8072767/bug8072767.java

2021-03-28 Thread Sergey Bylokhov
On Sun, 28 Mar 2021 00:21:16 GMT, Sergey Bylokhov wrote: > This test has a broken license: > /* > * To change this license header, choose License Headers in Project > Properties. > * To change this template file, choose Tools | Templates > /* > * Copyright (c) 20

RFR: 8264328: Broken license in javax/swing/JComboBox/8072767/bug8072767.java

2021-03-27 Thread Sergey Bylokhov
This test has a broken license: /* * To change this license header, choose License Headers in Project Properties. * To change this template file, choose Tools | Templates /* * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR

Re: RFR: 8264218: Public method javax.swing.JMenu.setComponentOrientation() has no spec

2021-03-26 Thread Sergey Bylokhov
On Fri, 26 Mar 2021 11:30:35 GMT, Prasanta Sadhukhan wrote: > A public overriding method > JMenu.setComponentOrientation(java.awt.ComponentOrientation) > has no spec. > Added spec for the method. Looks like the JavaDoc bug, the spec was there in jdk7:

Re: RFR: 8253266 : JList and JTable constructors should clear OPAQUE_SET before calling updateUI

2021-03-25 Thread Sergey Bylokhov
On Wed, 24 Mar 2021 06:17:04 GMT, Tejpal Rebari wrote: > Hi All, > Please review the following fix for jdk17. > > Issue : LookAndFeel.installProperty(list, "opaque", false) is not able to set > the opaque property for JList and JTable. > LookAndFeel.installProperty calls the setUIProperty, and

Re: RFR: 8263454: com.apple.laf.AquaFileChooserUI ignores the result of String.trim() [v2]

2021-03-24 Thread Sergey Bylokhov
On Tue, 23 Mar 2021 14:55:58 GMT, Alexander Zvegintsev wrote: >> Looks like the original idea was to set `fallbacktext` on strings containing >> only spaces. >> >> I decided to remove the `trim()` call to keep the same behavior and to >> allows to set such meaningless space only

Re: RFR: 8263768: JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter() spec doesn't mention what the default impls return and what does it mean [v4]

2021-03-24 Thread Sergey Bylokhov
On Wed, 24 Mar 2021 20:07:48 GMT, Alexey Ivanov wrote: > For my own clarification, does any change to the javadoc require a CSR? Any changes which add the new testable statements. Actually most change except typos/renames/format. - PR: https://git.openjdk.java.net/jdk/pull/3064

Re: RFR: 8263454: com.apple.laf.AquaFileChooserUI ignores the result of String.trim() [v2]

2021-03-23 Thread Sergey Bylokhov
On Tue, 23 Mar 2021 15:33:43 GMT, Alexander Zvegintsev wrote: >> src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java line >> 2059: >> >>> 2057: final String tooltipText = >>> fc.getApproveButtonToolTipText(); >>> 2058: if (tooltipText != null) { >>>

Re: RFR: 8263766: Confusing specification of JEditorPaneAccessibleHypertextSupport constructor

2021-03-23 Thread Sergey Bylokhov
On Tue, 23 Mar 2021 10:39:58 GMT, Pankaj Bansal wrote: >> The constructor JEditorPaneAccessibleHypertextSupport javadoc wording is >> wrong. Rectified the anomaly. > > Marked as reviewed by pbansal (Reviewer). where is a csr? - PR: https://git.openjdk.java.net/jdk/pull/3145

Re: RFR: 8263454: com.apple.laf.AquaFileChooserUI ignores the result of String.trim()

2021-03-22 Thread Sergey Bylokhov
On Mon, 22 Mar 2021 22:19:18 GMT, Alexander Zvegintsev wrote: > Looks like the original idea was to set `fallbacktext` on strings containing > only spaces. > > I decided to remove the `trim()` call to keep the same behavior and to allows > to set such meaningless space only

Re: RFR: 8263977: GTK L: Cleanup duplicate checks in GTKStyle and GTKLookAndFeel

2021-03-22 Thread Sergey Bylokhov
On Mon, 22 Mar 2021 15:40:41 GMT, Aleksey Shipilev wrote: > SonarCloud reports a few minor problems in GTKStyle and GTKLookAndFeel: > Correct one of the identical sub-expressions on both sides of operator "||". Looks fine, please update the dates. - Marked as reviewed by serb

Re: RFR: 8263768: JFormattedTextField.AbstractFormatter.getDocumentFilter()/getNavigationFilter() spec doesn't mention what the default impls return and what does it mean [v3]

2021-03-19 Thread Sergey Bylokhov
On Fri, 19 Mar 2021 19:50:20 GMT, Alexander Zvegintsev wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one >> additional commit since the last revision: >> >> @implNote added > > The bug's title is >

Re: RFR: 8263472: Specification of JComponent::updateUI doesn't mention that the original implementaiton does nothing [v6]

2021-03-18 Thread Sergey Bylokhov
On Thu, 18 Mar 2021 11:07:14 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - javadoc change >> - implNote change > > Marked as reviewed by aivanov (Reviewer). Do we need a CSR?

Re: RFR: 8262981: Create implementation for NSAccessibilitySlider protocol

2021-03-16 Thread Sergey Bylokhov
On Sun, 14 Mar 2021 11:10:09 GMT, Pankaj Bansal wrote: > It looks like the Dialog must have handled the keys as there are no special > keys mentioned for JAWS to interact with the component like the VO Did you check this list of hotkeys? https://www.freedomscientific.com/training/jaws/hotkeys

Re: RFR: 8263472: Specification of JComponent::updateUI doesn't mention that the original implementaiton does nothing [v2]

2021-03-15 Thread Sergey Bylokhov
On Mon, 15 Mar 2021 18:06:57 GMT, Alexey Ivanov wrote: >> src/java.desktop/share/classes/javax/swing/JComponent.java line 660: >> >>> 658: /** >>> 659: * Resets the UI property to a value from the current look and >>> feel. >>> 660: * Since the default implementation of this

Re: RFR: 8263472: Specification of JComponent::updateUI doesn't mention that the original implementaiton does nothing [v2]

2021-03-15 Thread Sergey Bylokhov
On Mon, 15 Mar 2021 04:23:26 GMT, Prasanta Sadhukhan wrote: >> It's unclear from the spec that the original implementation of the method >> JComponent.updateUI() does nothing which needs to be explicitly stated in >> the javadoc. > > Prasanta Sadhukhan has updated the pull request

Re: RFR: 8263472: Specification of JComponent::updateUI doesn't mention that the original implementaiton does nothing [v2]

2021-03-15 Thread Sergey Bylokhov
On Mon, 15 Mar 2021 10:44:51 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one >> additional commit since the last revision: >> >> javadoc change > > Marked as reviewed by aivanov (Reviewer). > I thought about it earlier but I raised this PR

Re: RFR: 8263136: C4530 was reported from VS 2019 at access bridge [v2]

2021-03-14 Thread Sergey Bylokhov
On Sun, 14 Mar 2021 17:27:58 GMT, Pankaj Bansal wrote: >> For the record: the jaws J2021.2102.34.400 was used for testing. > > @mrserb Did you close the JAWS after running the program. I have seen that > the logs for windows_access_bridge are flushed only after the JAWS is closed. Nope! thank

Re: RFR: 8263136: C4530 was reported from VS 2019 at access bridge [v2]

2021-03-12 Thread Sergey Bylokhov
On Wed, 10 Mar 2021 01:40:39 GMT, Sergey Bylokhov wrote: >> No, can you help? > > I'll check. This change looks fine, I was able to see the proper logs in the java_access_bridge.log, but I cannot find the logs from the windows_access_bridge.log. It seems unrelated to this fix. @p

Re: RFR: 8263136: C4530 was reported from VS 2019 at access bridge [v2]

2021-03-12 Thread Sergey Bylokhov
On Sat, 13 Mar 2021 01:56:06 GMT, Sergey Bylokhov wrote: >> I'll check. > > This change looks fine, I was able to see the proper logs in the > java_access_bridge.log, but I cannot find the logs from the > windows_access_bridge.log. It seems unrelated to this fix. @pankaj-ban

Re: RFR: 8263136: C4530 was reported from VS 2019 at access bridge [v2]

2021-03-12 Thread Sergey Bylokhov
On Mon, 8 Mar 2021 00:56:24 GMT, Yasumasa Suenaga wrote: >> I saw C4530 with VS 2019 (16.9.0) as following (on Japanese locale): >> >> AccessBridgeDebug.cpp >> メモ: インクルード ファイル: >> d:\github-forked\jdk\src\jdk.accessibility\windows\native\common\AccessBridgeDebug.h >> >> : >> >>

Re: RFR: 8263472: Specification of JComponent::updateUI doesn't mention that the original implementaiton does nothing

2021-03-12 Thread Sergey Bylokhov
On Fri, 12 Mar 2021 04:33:43 GMT, Prasanta Sadhukhan wrote: > It's unclear from the spec that the original implementation of the method > JComponent.updateUI() does nothing which needs to be explicitly stated in the > javadoc. Do we really want to specify this as a noop method? In this case,

Re: RFR: 8262981: Create implementation for NSAccessibilitySlider protocol

2021-03-11 Thread Sergey Bylokhov
On Thu, 11 Mar 2021 17:10:01 GMT, Pankaj Bansal wrote: > If you happen to have some idea about how can a user interact with Sliders or > Spinners using JAWS, please let me know. I will definitely verify if the > changes would be helpful for Windows. How the native applications works under

Re: RFR: 8262981: Create implementation for NSAccessibilitySlider protocol

2021-03-10 Thread Sergey Bylokhov
On Wed, 10 Mar 2021 14:47:02 GMT, Pankaj Bansal wrote: >>> If you need a new functionality and CSR I wonder how it currently works on >>> Windows and macOS, or it does not work? >> >> Haven't tested this functionality on Windows, on macOS with current JDK it >> does not work at all. After

Re: RFR: 8263136: C4530 was reported from VS 2019 at access bridge [v2]

2021-03-09 Thread Sergey Bylokhov
On Tue, 9 Mar 2021 00:49:09 GMT, Yasumasa Suenaga wrote: >> Did you check via some a11y tool that the new code actually works? > > No, can you help? I'll check. - PR: https://git.openjdk.java.net/jdk/pull/2859

Re: RFR: 8262981: Create implementation for NSAccessibilitySlider protocol

2021-03-09 Thread Sergey Bylokhov
On Mon, 8 Mar 2021 12:51:56 GMT, Pankaj Bansal wrote: > Create implementation of NSAccessibilitySlider protocol > https://developer.apple.com/documentation/appkit/nsaccessibilityslider > > The implementation has the function performIncrement and performDecrement to > increase/decrease the

Re: RFR: 8263170: ComboBoxModel documentation refers to a nonexistant type

2021-03-09 Thread Sergey Bylokhov
On Tue, 9 Mar 2021 21:32:08 GMT, Alexander Zuev wrote: >> javadoc of ComboBoxModel incorrectly specifies "extends ListDataModel" but >> actually it extends ListModel and there is no such interface as >> ListDataModel. Rectified the anomaly. > > Marked as reviewed by kizune (Reviewer). I

Re: RFR: 8182043: Access to Windows Large Icons

2021-03-09 Thread Sergey Bylokhov
On Mon, 8 Mar 2021 13:23:00 GMT, Alexander Zuev wrote: >> Fix updated after first round of review. > > Continuation of review at https://github.com/openjdk/jdk/pull/380 Just to continue the thread from the old review, did you have a chance to look at the possibility of loading all existed

Re: RFR: 8263136: C4530 was reported from VS 2019 at access bridge [v2]

2021-03-08 Thread Sergey Bylokhov
On Mon, 8 Mar 2021 07:46:54 GMT, Yasumasa Suenaga wrote: >> src/jdk.accessibility/windows/native/common/AccessBridgeDebug.cpp line 80: >> >>> 78: uli.LowPart = ft.dwLowDateTime; >>> 79: uli.HighPart = ft.dwHighDateTime; >>> 80: return (uli.QuadPart / 1ULL) - 1164447360ULL;

Re: RFR: 8263136: C4530 was reported from VS 2019 at access bridge

2021-03-07 Thread Sergey Bylokhov
On Sun, 7 Mar 2021 19:34:36 GMT, Thomas Stuefe wrote: > I wondered why C++ std headers are even used. The source code looks C-ish; > but "8196681: Java Access Bridge logging and debug flags dynamically > controlled" added some coding, adding a bunch of C++11x semantics and > included C++ std

Re: RFR: 8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button" [v3]

2021-03-04 Thread Sergey Bylokhov
On Thu, 4 Mar 2021 17:21:43 GMT, Alexander Zuev wrote: >> test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 115: >> >>> 113: Graphics g = fullScreen.getGraphics(); >>> 114: g.setColor(Color.RED); >>> 115: g.drawRect(locx - 1, locy - 1, frw + 1, frh

Re: RFR: 8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button" [v3]

2021-03-02 Thread Sergey Bylokhov
On Tue, 2 Mar 2021 22:08:48 GMT, Alexander Zuev wrote: >> test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 101: >> >>> 99: >>> 100: robot.waitForIdle(1000); >>> 101: robot.delay(1000); >> >> I doubt that this is a test issue, 2 seconds was not enough to

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

2021-03-02 Thread Sergey Bylokhov
On Tue, 2 Mar 2021 09:15:22 GMT, Alexander Zuev wrote: > 8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with > "Exception: Failed to hide opaque button" test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 101: > 99: > 100: robot.waitForIdle(1000); >

Re: RFR: 8262085: Hovering Metal HTML Tooltips in different windows cause IllegalArgExc on Linux [v2]

2021-02-27 Thread Sergey Bylokhov
On Sun, 28 Feb 2021 07:39:20 GMT, Alexander Zvegintsev wrote: >> This issue occurs only under `MetalLookAndFeel` on Linux. >> >> It was introduced by >> [JDK-8040630](https://bugs.openjdk.java.net/browse/JDK-8040630) fix. >> >>> component.setBounds(ownerX, ownerY, 1, 1); >> >> This line

Re: RFR: 8262085: Hovering Metal HTML Tooltips in different windows cause IllegalArgExc on Linux

2021-02-27 Thread Sergey Bylokhov
On Sat, 27 Feb 2021 21:56:47 GMT, Sergey Bylokhov wrote: >> This issue occurs only under `MetalLookAndFeel` on Linux. >> >> It was introduced by >> [JDK-8040630](https://bugs.openjdk.java.net/browse/JDK-8040630) fix. >> >>> component.setBounds(owner

Re: RFR: 8262085: Hovering Metal HTML Tooltips in different windows cause IllegalArgExc on Linux

2021-02-27 Thread Sergey Bylokhov
On Sat, 27 Feb 2021 17:02:13 GMT, Alexander Zvegintsev wrote: > This issue occurs only under `MetalLookAndFeel` on Linux. > > It was introduced by > [JDK-8040630](https://bugs.openjdk.java.net/browse/JDK-8040630) fix. > >> component.setBounds(ownerX, ownerY, 1, 1); > > This line adds an

Re: RFR: 8262161 Refactor manual I/O stream copying to new convinient methods in java.desktop

2021-02-26 Thread Sergey Bylokhov
On Wed, 24 Feb 2021 20:48:29 GMT, Phil Race wrote: >> Cleanup code to use new handy methods in >> `java.io.InputStream`/`java.nio.file.Files` instead of manual stream copy: >> 1. java.io.InputStream#readAllBytes >> 2. java.io.InputStream#transferTo >> 3. java.nio.file.Files#copy >> >> Similar

Re: RFR: 4710675: JTextArea.setComponentOrientation does not work with correct timing [v3]

2021-02-25 Thread Sergey Bylokhov
On Fri, 26 Feb 2021 05:32:06 GMT, Prasanta Sadhukhan wrote: >> It is seen >> JTextArea.setComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) >> orientation is not honoured if it is called after setText() and remain at >> LTR orientation. It changes the orientation only if some more

Re: RFR: 4710675: JTextArea.setComponentOrientation does not work with correct timing [v2]

2021-02-25 Thread Sergey Bylokhov
On Thu, 25 Feb 2021 04:37:01 GMT, Prasanta Sadhukhan wrote: >> It is seen >> JTextArea.setComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT) >> orientation is not honoured if it is called after setText() and remain at >> LTR orientation. It changes the orientation only if some more

Re: RFR: 8262161 Refactor manual I/O stream copying to new convinient methods in java.desktop

2021-02-25 Thread Sergey Bylokhov
On Mon, 21 Dec 2020 07:54:17 GMT, Andrey Turbanov wrote: > Cleanup code to use new handy methods in > `java.io.InputStream`/`java.nio.file.Files` instead of manual stream copy: > 1. java.io.InputStream#readAllBytes > 2. java.io.InputStream#transferTo > 3. java.nio.file.Files#copy > > Similar

<    1   2   3   4   5   6   7   8   9   10   >