On Thu, 17 Feb 2022 17:54:43 GMT, DamonGuy <d...@openjdk.java.net> wrote:
>> Html does not fit in JButton at certain sizes because default Insets cause >> html to be displayed off-center. >> >> Changes made to SwingUtilities.java layoutCompoundLabelImpl method to enable >> clipping if html does not fit, similar to regular text. AquaButtonUI.java >> now detects when html does not fit, and an implementation for alternate >> insets that are recursively tested for regular text inside >> layoutAndGetText() are now also being used for html content. >> >> Created test (Bug8015854.java) with the same format as the test described on >> the issue. The button is of size 37x37 with an image of a red square sized >> 19x19. The test checks for red pixels on the edges of where the square image >> should be from the center of the button. The test fails with the non-changed >> jdk, but passes with the changes. > > DamonGuy has updated the pull request incrementally with one additional > commit since the last revision: > > Fixed incomplete comment. src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 313: > 311: // use zero insets for view since layout only handles text > calculations > 312: text = layoutAndGetText(g, b, aquaBorder, new > 313: Insets(0,0,0,0), viewRect, iconRect, textRect); If there is only html text instead of image in JButton, will it not be a problem using 0 insets or is there a problem with text too being shifted like image? test/jdk/javax/swing/JButton/HtmlButtonImageTest/HtmlButtonImageTest.java line 69: > 67: > 68: Robot robot = new Robot(); > 69: robot.setAutoDelay(2000); autodelay is normally set to 100. Dont think one would want to wait 2 secs between robot events. test/jdk/javax/swing/JButton/HtmlButtonImageTest/HtmlButtonImageTest.java line 81: > 79: createAndShowGUI(); > 80: }); > 81: normally it is recommended to wait for a sec after frame is visible and before start of robot events. test/jdk/javax/swing/JButton/HtmlButtonImageTest/HtmlButtonImageTest.java line 85: > 83: robot.mouseMove(frame.getLocationOnScreen().x, > frame.getLocationOnScreen().y); > 84: robot.mouseMove(button.getLocationOnScreen().x, > button.getLocationOnScreen().y); > 85: I guess there is no need of this staggard mouseMove. One can move straight to "point" as done below, right? test/jdk/javax/swing/JButton/HtmlButtonImageTest/HtmlButtonImageTest.java line 93: > 91: Color rightClr = robot.getPixelColor(point.x + (SQUARE_WIDTH/2) - > PIXEL_BUFFER, point.y); > 92: Color topClr = robot.getPixelColor(point.x, point.y - > (SQUARE_HEIGHT/2) + PIXEL_BUFFER); > 93: Color botClr = robot.getPixelColor(point.x, point.y + > (SQUARE_HEIGHT/2) - PIXEL_BUFFER); there was an issue of using getPixelColor on retina screen on mac laptop as @honkar-jdk found out in #[7219](https://git.openjdk.java.net/jdk/pull/7219)..She has to use BufferedImage..Are you sure this is working on all mac CI system, mac external monitor and mac laptop? test/jdk/javax/swing/JButton/HtmlButtonImageTest/HtmlButtonImageTest.java line 98: > 96: SwingUtilities.invokeAndWait(() -> { > 97: frame.dispose(); > 98: }); normally we dispose frame in try-finally block ------------- PR: https://git.openjdk.java.net/jdk/pull/7310
