On Mon, 23 Aug 2021 12:32:20 GMT, Prasanta Sadhukhan
wrote:
> It is seen that if a JTabbedPane is unfocused, it's title is painted with
> **white** text on grey background
> as opposed to **black** text on grey background in unfoucsed native app on
> macOSX Catalina
>
On Sat, 4 Sep 2021 11:06:14 GMT, Prasanta Sadhukhan
wrote:
>> You need to override the paintIcon method in the InvertableImageIcon
>> returned by the AquaImageFactory.getMenuArrowIcon() or you can create `class
>> MenuArrowIcon extends InvertableImageIcon,` and override it
On Mon, 6 Sep 2021 08:00:36 GMT, Prasanta Sadhukhan
wrote:
>> It is seen that if a JTabbedPane is unfocused, it's title is painted with
>> **white** text on grey background
>> as opposed to **black** text on grey background in unfoucsed native app on
>> macOS
On Wed, 11 Aug 2021 09:03:57 GMT, Prasanta Sadhukhan
wrote:
> The test fails in CI testing citing expected "rededited" but found
> "redEDITED", which seems to point to fact that either there is a CAPS_LOCK
> key switched on or some other test did not use SHIFT key
On Fri, 3 Sep 2021 05:54:45 GMT, Sergey Bylokhov wrote:
>> I will like to know how because as it is pointed out, paintArrow delegates
>> drawing to ImageIcon#paintIcon which is in shared code and this is mac
>> specific issue so it needs to be handled before we call ImageIcon#paintIcon
>
> You
> Proposed fix is to generate a disabled ImageIcon image of the same arrow icon
> and use it for disabled state.
Prasanta Sadhukhan has updated the pull request incrementally with one
additional commit since the last revision:
Add menuitem checkicon test
-
Changes:
- all
> Proposed fix is to generate a disabled ImageIcon image of the same arrow icon
> and use it for disabled state.
Prasanta Sadhukhan has updated the pull request incrementally with two
additional commits since the last revision:
- Override paintIcon
- Override paintIcon
> Proposed fix is to generate a disabled ImageIcon image of the same arrow icon
> and use it for disabled state.
Prasanta Sadhukhan has updated the pull request incrementally with one
additional commit since the last revision:
Override paintIcon
-
Changes:
- all: https://g
On Thu, 2 Sep 2021 18:10:55 GMT, Sergey Bylokhov wrote:
>> Prasanta Sadhukhan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Cache icon
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaMenuPa
> Proposed fix is to generate a disabled ImageIcon image of the same arrow icon
> and use it for disabled state.
Prasanta Sadhukhan has updated the pull request incrementally with one
additional commit since the last revision:
Cache icon
-
Changes:
- all: https://git.openj
On Thu, 2 Sep 2021 10:48:40 GMT, Sergey Bylokhov wrote:
>> That is for MenuArrowIcon which is also there for Metal and Windows L&F in
>> addition with MenuItemArrowIcon(). Aqua does not have it for MenuItem.
>> The control for aqua menuitem goes via ImageIcon#paintIcon for menuitem
>> arrow whi
On Thu, 2 Sep 2021 09:26:16 GMT, Sergey Bylokhov wrote:
>> In other L&Fs, it creates their own icon
>> for ex, MetalLookAndFeel
>> "MenuItem.arrowIcon",(LazyValue) t ->
>> MetalIconFactory.getMenuItemArrowIcon(),
>> and WindowsLookAndFeel
>> "MenuItem.arrowIcon", menuItemArrowIcon,
>>
>> but f
On Thu, 2 Sep 2021 04:46:48 GMT, Sergey Bylokhov wrote:
>> In MenuArrowIcon, the arrow icon is drawn there itself using drawPolygon but
>> in Aqua, it is drawn via imageicon image so it will be a change in design
>> and will make it more complex and it might introduce bug in hidpi/retina. I
>>
On Wed, 1 Sep 2021 23:57:07 GMT, Sergey Bylokhov wrote:
>> It is seen in macos disabled JMenuItem arrow is not disabled even though
>> JMenuItem itself is disabled.
>> In native app, same menuitem arrow is disabled for disabled menuitem.
>>
>> Issue is when AquaMenuPainter#paintMenuItem() is ca
On Tue, 31 Aug 2021 22:35:10 GMT, Sergey Bylokhov wrote:
>
>
> > In native app, same menuitem arrow is disabled for disabled menuitem.
>
> How it will work if the "apple.laf.useScreenMenuBar" property is set, will
> the arrow look the same(disabled) as after this fix?
Yes, it is disabled.
-
It is seen in macos disabled JMenuItem arrow is not disabled even though
JMenuItem itself is disabled.
In native app, same menuitem arrow is disabled for disabled menuitem.
Issue is when AquaMenuPainter#paintMenuItem() is called, it tries to draw a
ImageIcon image of the arrow via ImageIcon#pain
On Thu, 19 Aug 2021 06:13:39 GMT, Prasanta Sadhukhan
wrote:
> This is another attempt of fixing JDK-8249674 which created a regression
> JDK-8266510 for which it was backed out.
> This fix reinstates the UIResource properties for "Tree.leafIcon",
> "Tree.c
l || color instanceof UIResource) {
> // Then use what we've locally defined
> color = getColorForState(context, type);
> }
>
>
> Proposed fix is to check if current foregroundColor for
> DefaultTreeCellRenderer is UIResouce, then use
l || color instanceof UIResource) {
> // Then use what we've locally defined
> color = getColorForState(context, type);
> }
>
>
> Proposed fix is to check if current foregroundColor for
> DefaultTreeCellRenderer is UIResouce, then use
On Wed, 25 Aug 2021 04:11:55 GMT, Prasanta Sadhukhan
wrote:
>> This is another attempt of fixing JDK-8249674 which created a regression
>> JDK-8266510 for which it was backed out.
>> This fix reinstates the UIResource properties for "Tree.leafIcon",
>>
l || color instanceof UIResource) {
> // Then use what we've locally defined
> color = getColorForState(context, type);
> }
>
>
> Proposed fix is to check if current foregroundColor for
> DefaultTreeCellRenderer is UIResouce, then use th
On Thu, 19 Aug 2021 06:13:39 GMT, Prasanta Sadhukhan
wrote:
> This is another attempt of fixing JDK-8249674 which created a regression
> JDK-8266510 for which it was backed out.
> This fix reinstates the UIResource properties for "Tree.leafIcon",
> "Tree.c
On Wed, 4 Aug 2021 09:02:25 GMT, Prasanta Sadhukhan
wrote:
> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called
> with null value. There are many places in JInternalFrame where
> getDesktopIcon() is accessed without null check which might cause NPE.
>
> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called
> with null value. There are many places in JInternalFrame where
> getDesktopIcon() is accessed without null check which might cause NPE.
> Added null check for those cases.
Prasanta Sadhukhan has upda
It is seen that if a JTabbedPane is unfocused, it's title is painted with
**white** text on grey background
as opposed to **black** text on grey background in unfoucsed native app on
macOSX Catalina
and is somewhat not legible.
This can be seen with SwingSet2 demo with InternalFrame or JTabbed
> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called
> with null value. There are many places in JInternalFrame where
> getDesktopIcon() is accessed without null check which might cause NPE.
> Added null check for those cases.
Prasanta Sadhukhan has upda
On Thu, 19 Aug 2021 17:10:27 GMT, Alexey Ivanov wrote:
> As an experiment, is it possible to log the current state of modifier keys,
> i.e. Shift, Control, Alt, before the key events are sent to edited table
> cell? This would confirm our guess whether Shift key is left pressed by a
> test whi
On Thu, 19 Aug 2021 16:48:46 GMT, Prasanta Sadhukhan
wrote:
>> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be
>> called with null value. There are many places in JInternalFrame where
>> getDesktopIcon() is accessed without null check which might ca
> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called
> with null value. There are many places in JInternalFrame where
> getDesktopIcon() is accessed without null check which might cause NPE.
> Added null check for those cases.
Prasanta Sadhukhan has upda
On Mon, 16 Aug 2021 20:48:45 GMT, Pankaj Bansal wrote:
> The "InternalFrame.useTaskBar" is set true in case of GTKL&F only,
What if we set this property to false and only set under some condition for GTK
L&F, what sort of problem we can expect? Does any jtreg/jck test gets affected
if we set
On Tue, 17 Aug 2021 12:35:02 GMT, Alexey Ivanov wrote:
>
>
> > Since FIRST failure is
> > java/awt/SplashScreen/MultiResolutionSplash/MultiResolutionSplashTest.java
> > I tried to find tests that uses VK_SHIFT key which are …
>
> Can you reproduce the failure locally if the tests are run in t
This is another attempt of fixing JDK-8249674 which created a regression
JDK-8266510 for which it was backed out.
This fix reinstates the UIResource properties for "Tree.leafIcon",
"Tree.closedIcon", "Tree.openIcon", "Tree.selectionForeground",
"Tree.textForeground", "Tree.selectionBackground"
On Tue, 17 Aug 2021 06:09:51 GMT, Alexander Zuev wrote:
>> Initial implementation and a test case.
>>
>> The problem is that Aqua LaF shows the focused component with the glow on
>> the border, hence when the border is not painted the foxus is not displayed.
>> The idea is to paint the glowing
On Tue, 17 Aug 2021 06:04:39 GMT, Alexander Zuev wrote:
>> You can trace the usage of graphics.getColor() for example in
>> AquaMenuItemUI/WindowsMenuUI/BevelBorder/etc to check that the old color
>> property is usually saved and then restored.
>
>> You can trace the usage of graphics.getColor(
On Mon, 16 Aug 2021 21:10:10 GMT, Phil Race wrote:
>>> We should either prevent null being set or catch all those nulls.
>>
>> I did that in 1st iteration of this
>> PR..https://github.com/openjdk/jdk/pull/4989/files/2a2ab50ded3305f3a9e0f01e90417b484a0b2db4
>>
>>
>> @prrace Should I bring th
On Tue, 17 Aug 2021 12:27:35 GMT, Alexey Ivanov wrote:
> And using robot to release keys from EDT as part of the clean-up doesn't seem
> right.
I am just rectifying the order of the key release..It was pressed in order ALT
SHIFT CONTROL and the release was ALT SHIFT CONTROL.. which I rectified
On Mon, 16 Aug 2021 13:45:49 GMT, Prasanta Sadhukhan
wrote:
>> The test fails in CI testing citing expected "rededited" but found
>> "redEDITED", which seems to point to fact that either there is a CAPS_LOCK
>> key switched on or some other test did not u
f such CAPS_LOCK or Shift key problem happens again,
> this test will not be affected.
>
> CI run for several iterations running these 2 tests one after another in all
> platforms is green.
Prasanta Sadhukhan has updated the pull request incrementally with one
additional commit sinc
On Tue, 17 Aug 2021 05:09:10 GMT, Sergey Bylokhov wrote:
>> Prasanta Sadhukhan has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Prevent null being set
>> - Prevent null being set
>
> src/ja
> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called
> with null value. There are many places in JInternalFrame where
> getDesktopIcon() is accessed without null check which might cause NPE.
> Added null check for those cases.
Prasanta Sadhukhan has upda
f such CAPS_LOCK or Shift key problem happens again,
> this test will not be affected.
>
> CI run for several iterations running these 2 tests one after another in all
> platforms is green.
Prasanta Sadhukhan has updated the pull request incrementally with one
additional c
On Wed, 11 Aug 2021 09:03:57 GMT, Prasanta Sadhukhan
wrote:
> The test fails in CI testing citing expected "rededited" but found
> "redEDITED", which seems to point to fact that either there is a CAPS_LOCK
> key switched on or some other test did not use SHIFT key
On Sat, 14 Aug 2021 18:50:58 GMT, Phil Race wrote:
> We should either prevent null being set or catch all those nulls.
I did that in 1st iteration of this
PR..https://github.com/openjdk/jdk/pull/4989/files/2a2ab50ded3305f3a9e0f01e90417b484a0b2db4
@prrace Should I bring that fix back?
> Just
On Sat, 14 Aug 2021 19:14:06 GMT, Phil Race wrote:
> am curious how Prasanta decided
> test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java might be the problem
As I told in initial explanation, I thought it will be either CAPS_LOCK key
switched on or some other test did not use SHIFT ke
On Fri, 13 Aug 2021 06:18:49 GMT, Alexander Zuev wrote:
>> Initial implementation and a test case.
>>
>> The problem is that Aqua LaF shows the focused component with the glow on
>> the border, hence when the border is not painted the foxus is not displayed.
>> The idea is to paint the glowing
On Thu, 29 Jul 2021 11:44:31 GMT, Prasanta Sadhukhan
wrote:
> The Nimbus look and feel ignores the configured background color of a
> JTextPane and always uses white.
> Every other look and feel tested (Metal, Motif, and Windows) correctly honors
> the configured backgroun
On Thu, 12 Aug 2021 22:31:08 GMT, Sergey Bylokhov wrote:
>> I guess that is why we are putting up this statement, no so that user thinks
>> twice before making it null? Should we make the field private?
>
> We cannot make it private, we can only update the spec there as well.
done
> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called
> with null value. There are many places in JInternalFrame where
> getDesktopIcon() is accessed without null check which might cause NPE.
> Added null check for those cases.
Prasanta Sadhukhan has upda
On Wed, 11 Aug 2021 09:03:57 GMT, Prasanta Sadhukhan
wrote:
> The test fails in CI testing citing expected "rededited" but found
> "redEDITED", which seems to point to fact that either there is a CAPS_LOCK
> key switched on or some other test did not use SHIFT key
On Thu, 12 Aug 2021 02:20:51 GMT, Sergey Bylokhov wrote:
>> Prasanta Sadhukhan has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove test
>> - Update javadoc clarification
>
> src/ja
On Mon, 9 Aug 2021 04:21:08 GMT, Prasanta Sadhukhan
wrote:
>> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be
>> called with null value. There are many places in JInternalFrame where
>> getDesktopIcon() is accessed without null check which might ca
On Wed, 11 Aug 2021 11:22:50 GMT, Alexander Zuev wrote:
> Initial implementation and a test case.
>
> The problem is that Aqua LaF shows the focused component with the glow on the
> border, hence when the border is not painted the foxus is not displayed. The
> idea is to paint the glowing bord
The test fails in CI testing citing expected "rededited" but found "redEDITED",
which seems to point to fact that either there is a CAPS_LOCK key switched on
or some other test did not use SHIFT key corectly ie, pressed but not released.
Considering many more tests would have failed if CAPS_LOC
ground color in nimbus skin which is
> rectified via the fix.
> After this fix, the background color is correctly updated to whatever is
> being set via JTextPane.setBackground().
>
> CI all test run is green.
Prasanta Sadhukhan has updated the pull request incrementally with on
On Mon, 9 Aug 2021 15:08:13 GMT, Alexey Ivanov wrote:
>> Prasanta Sadhukhan has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Fix
>> - Merge test
>
> test/jdk/javax/swing/plaf/nimbus/TestNimbusBGCo
On Mon, 9 Aug 2021 15:06:55 GMT, Phil Race wrote:
>> As per the bug comments, these tests fail too often on macOS arm.
>> This will be too noisy for CI. So I would like to problem list them for
>> mac-arm
>
> Phil Race has updated the pull request incrementally with one additional
> commit sin
ground color in nimbus skin which is
> rectified via the fix.
> After this fix, the background color is correctly updated to whatever is
> being set via JTextPane.setBackground().
>
> CI all test run is green.
Prasanta Sadhukhan has updated the pull request incrementally with on
ground color in nimbus skin which is
> rectified via the fix.
> After this fix, the background color is correctly updated to whatever is
> being set via JTextPane.setBackground().
>
> CI all test run is green.
Prasanta Sadhukhan has updated the pull request incrementally with two
On Mon, 9 Aug 2021 13:01:17 GMT, Alexey Ivanov wrote:
>
>
> > > The tests are nearly the same: the only difference is the component being
> > > tested. I suggest merging the two tests into one test which tests both
> > > components one after another.
> >
> >
> > I would rather have as separ
On Wed, 4 Aug 2021 21:23:48 GMT, Alexey Ivanov wrote:
>
>
> The tests are nearly the same: the only difference is the component being
> tested. I suggest merging the two tests into one test which tests both
> components one after another.
I would rather have as separate test as the fix is in
On Thu, 5 Aug 2021 08:37:07 GMT, Prasanta Sadhukhan
wrote:
>> The Nimbus look and feel ignores the configured background color of a
>> JTextPane and always uses white.
>> Every other look and feel tested (Metal, Motif, and Windows) correctly
>> honors the configur
On Mon, 9 Aug 2021 04:28:28 GMT, Sergey Bylokhov wrote:
>> As per the bug comments, these tests fail too often on macOS arm.
>> This will be too noisy for CI. So I would like to problem list them for
>> mac-arm
>
> test/jdk/ProblemList.txt line 532:
>
>> 530:
>> 531: java/awt/Window/GetScreen
> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called
> with null value. There are many places in JInternalFrame where
> getDesktopIcon() is accessed without null check which might cause NPE.
> Added null check for those cases.
Prasanta Sadhukhan has upda
On Thu, 5 Aug 2021 08:37:07 GMT, Prasanta Sadhukhan
wrote:
>> The Nimbus look and feel ignores the configured background color of a
>> JTextPane and always uses white.
>> Every other look and feel tested (Metal, Motif, and Windows) correctly
>> honors the configur
ground color in nimbus skin which is
> rectified via the fix.
> After this fix, the background color is correctly updated to whatever is
> being set via JTextPane.setBackground().
>
> CI all test run is green.
Prasanta Sadhukhan has updated the pull request incrementally with on
On Wed, 4 Aug 2021 23:06:35 GMT, Sergey Bylokhov wrote:
>> It looks the fix doesn't work or alternatively it works in an unexpected way.
>>
>> Both JEditorPane and JTextPane used to have white background but now, with
>> these changes, their background is the same of the panel below. It's
>> p
On Wed, 4 Aug 2021 09:02:25 GMT, Prasanta Sadhukhan
wrote:
> JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called
> with null value. There are many places in JInternalFrame where
> getDesktopIcon() is accessed without null check which might cause NPE.
>
On Tue, 3 Aug 2021 08:23:19 GMT, Prasanta Sadhukhan
wrote:
> In the JTable demo, if we double click on the first cell in the Favorite
> Number column, delete the value and click on some
> other cell, a java.lang.NullPointerException is getting thrown.
> The flaw is in the
the value of cell 0 in the target column, and returns its Class. This
> logic seems to be flawed - an NPE will be thrown when the value in cell 0 is
> null.
> Fix by checking for null.
Prasanta Sadhukhan has updated the pull request incrementally with one
additional commit since the
On Mon, 2 Aug 2021 09:17:05 GMT, Prasanta Sadhukhan
wrote:
> The method show() in the JOptionPane javadoc example is deprecated. The
> recommended method to call would be setVisible(true).
This pull request has now been integrated.
Changeset: 4df1bc4b
Author:Prasanta Sadhukha
JInternalFrame.getDesktopIcon() can be null as setDesktopIcon() can be called
with null value. There are many places in JInternalFrame where getDesktopIcon()
is accessed without null check which might cause NPE.
Added null check for those cases.
-
Commit messages:
- 5015261: JInte
On Tue, 3 Aug 2021 06:34:28 GMT, Prasanta Sadhukhan
wrote:
>> Does it mean that "shapes" tag is not used and we can remove all its usage
>> in the file?
>
> I dont know. I am only telling by looking at source code..I dont know what
> NimbusL&F creator mean
In the JTable demo, if we double click on the first cell in the Favorite Number
column, delete the value and click on some
other cell, a java.lang.NullPointerException is getting thrown.
The flaw is in the TableDemo's TableModel getColumnClass() method which queries
the value of cell 0 in the tar
On Tue, 3 Aug 2021 06:28:59 GMT, Sergey Bylokhov wrote:
>> Yes, I meant the grey background what is being described in
>> EditorPane.background and TextPane.background is what is being shown now,
>> not literally NimbusBlueGrey. Till now we were showing white which is in
>> contrary to this de
On Tue, 3 Aug 2021 06:03:21 GMT, Sergey Bylokhov wrote:
>> I have looked at
>> https://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/_nimbusDefaults.html
>> where default color for
>> EditorPane.background and TextPane.background is NimbusBlueGrey and not
>> White what we have now, so I
On Mon, 2 Aug 2021 22:13:24 GMT, Sergey Bylokhov wrote:
>> Prasanta Sadhukhan has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Fix
>> - JEditorpane background color fix
>
> src/java.desktop/s
The method show() in the JOptionPane javadoc example is deprecated. The
recommended method to call would be setVisible(true).
-
Commit messages:
- 6350025: API documentation for JOptionPane using deprecated methods.
Changes: https://git.openjdk.java.net/jdk/pull/4953/files
Webrev:
On Fri, 30 Jul 2021 20:42:57 GMT, Alexey Ivanov wrote:
>> Prasanta Sadhukhan has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Fix
>> - JEditorpane background color fix
>
> test/jdk/javax/swing/plaf/
ground color in nimbus skin which is
> rectified via the fix.
> After this fix, the background color is correctly updated to whatever is
> being set via JTextPane.setBackground().
>
> CI all test run is green.
Prasanta Sadhukhan has updated the pull request incrementally with two
On Fri, 30 Jul 2021 20:39:24 GMT, Alexey Ivanov wrote:
>
>
> Does the JEditorPane have the same issue?
> https://bugs.openjdk.java.net/browse/JDK-6789980
Yes, fixed
-
PR: https://git.openjdk.java.net/jdk/pull/4930
On Fri, 30 Jul 2021 15:17:41 GMT, Alexander Zvegintsev
wrote:
>> I have taken care of NPE..I am not sure of switch which probably might be a
>> hindrance in backporting if needed to earlier release trains.
>> CI is also run..link in JBS.
>
>> I am not sure of switch which probably might be a hi
On Fri, 30 Jul 2021 06:04:17 GMT, Prasanta Sadhukhan
wrote:
> JComponent.setUIProperty method uses string identity check (==) rather than
> string equality checks (.equals) when comparing against the property name.
> This is suspicious since string identity and equality and equiva
On Fri, 30 Jul 2021 09:32:10 GMT, Alexander Zvegintsev
wrote:
>> Prasanta Sadhukhan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Prevent NPE
>
> src/java.desktop/share/classes/javax/swing/JCompon
e String.equals() check.
Prasanta Sadhukhan has updated the pull request incrementally with one
additional commit since the last revision:
Prevent NPE
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/4943/files
- new: https://git.openjdk.java.net/jdk/pull/4943/files/bd4
On Tue, 27 Jul 2021 02:46:53 GMT, Yi Yang wrote:
>> I meant
>>
>> if (imageIndex < minIndex)
>> throw new IndexOutOfBoundsException();
>>
>> can't it be replaced with Objects.checkFromToIndex(minIndex, imageIndex, ..
>
> Hi, sorry for the late response. checkFromToIndex has
On Thu, 22 Jul 2021 06:29:13 GMT, Yi Yang wrote:
>> After JDK-8265518(#3615), it's possible to replace all variants of
>> checkIndex by
>> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
>> the whole JDK codebase.
>>
>> As Mandy suggested, I create this PR for change
JComponent.setUIProperty method uses string identity check (==) rather than
string equality checks (.equals) when comparing against the property name. This
is suspicious since string identity and equality and equivalent only for
interned strings.
Rectified to use String.equals() check.
---
On Thu, 29 Jul 2021 11:44:31 GMT, Prasanta Sadhukhan
wrote:
> The Nimbus look and feel ignores the configured background color of a
> JTextPane and always uses white.
> Every other look and feel tested (Metal, Motif, and Windows) correctly honors
> the configured backgroun
The Nimbus look and feel ignores the configured background color of a JTextPane
and always uses white.
Every other look and feel tested (Metal, Motif, and Windows) correctly honors
the configured background color of a JTextPane.
Issue seems to be in the hardcoded background color in nimbus skin
On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg
wrote:
> This PR fixes the following spelling errors:
>
> choosen -> chosen
> commad -> command
> hiearchy -> hierarchy
> leagacy -> legacy
> minium -> minimum
> subsytem -> subsystem
> unamed -> unnamed
Thanks for awt/swing correc
On Wed, 28 Jul 2021 07:24:38 GMT, Prasanta Sadhukhan
wrote:
> This test was failing in CI test run due to timing issue. Adjusted robot
> delay..Also, made frame to show in middle of screen and dispose of frame at
> end.
> CI test run is green.
This pull request has now bee
This test was failing in CI test run due to timing issue. Adjusted robot
delay..Also, made frame to show in middle of screen and dispose of frame at end.
CI test run is green.
-
Commit messages:
- Fix
- 8137101: [TEST_BUG] javax/swing/plaf/basic/BasicHTML/4251579/bug4251579.java
f
On Mon, 26 Jul 2021 05:46:44 GMT, Tejpal Rebari wrote:
> Please review the following fix for JDK-18.
> This is revert of the fix for nimbus jtree renderer properties persist
> across L&F(https://bugs.openjdk.java.net/browse/JDK-8249674), This fixed
> caused nimbus jtree default tree cell rende
On Thu, 22 Jul 2021 06:23:43 GMT, Yi Yang wrote:
>> test/jdk/javax/imageio/ImageReaderReadAll.java line 94:
>>
>>> 92: if (seekForwardOnly) {
>>> 93: if (imageIndex < minIndex)
>>> 94: throw new IndexOutOfBoundsException();
>>
>> Can't we use chec
On Wed, 21 Jul 2021 09:58:23 GMT, Yi Yang wrote:
>> After JDK-8265518(#3615), it's possible to replace all variants of
>> checkIndex by
>> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
>> the whole JDK codebase.
>>
>> As Mandy suggested, I create this PR for change
On Thu, 15 Jul 2021 11:27:39 GMT, Alexander Zuev wrote:
> Reducing the height of the analyzed area to get rid of the rounded edges
> at the botom of the frame. Apparently shadow outside of it being
> rendered by Mac OS X Big Sur inconsistently which gives random test
> failures on M1 macs with Bi
On Tue, 29 Jun 2021 08:29:29 GMT, Christoph Langer wrote:
>> Exclude test on Windows if VM is from a debug build.
>
> Christoph Langer has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Update Copyright year
Marked as reviewed by psadhukhan (
On Mon, 28 Jun 2021 15:43:35 GMT, Christoph Langer wrote:
>> Exclude test on Windows if VM is from a debug build.
>
> Christoph Langer has refreshed the contents of this pull request, and
> previous commits have been removed. The incremental views will show
> differences compared to the previou
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.
This pull request has now been integrated.
Changeset: e48d7d66
Author: Prasan
On Mon, 17 May 2021 09:05:06 GMT, Prasanta Sadhukhan
wrote:
> This testcase has failed intermittently in CI testing citing icon and
> ImageIcon images are not same.
> It's been observed that the rectangle been passed to
> Robot.createScreenCapture was incorrect to compare th
1 - 100 of 1301 matches
Mail list logo